Luận văn Thạc sĩ Công nghệ thông tin: Nghiên cứu phương pháp quản trị rủi ro hướng mục tiêu và thử nghiệm ứng dụng trong xây dựng cổng thông tin điện tử Bộ GTVT

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

---------------------------------------

Vũ Thị Hoa

NGHIÊN CỨU PHƯƠNG PHÁP QUẢN TRỊ RỦI RO

HƯỚNG MỤC TIÊU VÀ THỬ NGHIỆM ỨNG DỤNG TRONG XÂY

DỰNG CỔNG THÔNG TIN ĐIỆN TỬ BỘ GTVT

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

Hà Nội – 2017

BỘ GIÁO DỤC VÀ ĐÀO TẠO

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

Vũ Thị Hoa

NGHIÊN CỨU PHƯƠNG PHÁP QUẢN TRỊ RỦI RO

HƯỚNG MỤC TIÊU VÀ THỬ NGHIỆM ỨNG DỤNG TRONG

XÂY DỰNG CỔNG THÔNG TIN ĐIỆN TỬ BỘ GTVT

Chuyên ngành: Công nghệ thông tin

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

…......................................

NGƯỜI HƯỚNG DẪN KHOA HỌC:

PGS. TS. HUỲNH QUYẾT THẮNG

Hà Nội – 2017

LỜI CẢM ƠN

Lời đầu tiên tôi xin chân thành cảm ơn các thầy cô giáo ở Viện Công nghệ

thông tin và Truyền thông, ở Trường Đại học Bách Khoa Hà Nội đã giảng dạy tôi

trong suốt khóa học, cung cấp những kiến thức cần thiết, cơ sở lý luận khoa học để

tôi có thể hoàn thành bài luận văn này.

Tôi xin gửi lời cảm ơn sâu sắc tới PGS.TS Huỳnh Quyết Thắng đã tận tình chỉ

bảo, giúp đỡ tôi trong suốt quá trình làm luận văn.

Tôi xin chân thành cảm ơn các thầy cô giáo trong Viện Đào tạo Sau đại học,

Viện CNTT-TT đã tạo điều kiện và giúp đỡ tôi trong quá trình học tập và nghiên

cứu tại trường.

Xin cảm ơn những bạn bè trong tập thể lớp CNTT15B đã chung vai sát cánh

vượt qua những khó khăn, thử thách, cùng nhau vững bước trên con đường học tập

đầy gian nan, vất vả.

Xin trân trọng cảm ơn!

LỜI CAM ĐOAN

Tôi xin cam đoan: Luận văn " Nghiên cứu phương pháp quản trị rủi ro hướng

mục tiêu và thử nghiệm ứng dụng trong xây dựng cổng thông tin điện tử Bộ GTVT "

là do bản thân tôi thực hiện dưới sự hướng dẫn của PGS.TS. Huỳnh Quyết Thắng,

Viện Công nghệ thông tin và Truyền thông, Trường ĐH Bách khoa Hà Nội.

Các thông tin số liệu và kết quả trong Luận văn có nguồn gốc rõ ràng, nội

dung của Luận văn chưa từng được công bố trong bất kỳ một công trình nghiên cứu

nào ở trong nước.

Hà Nội, tháng năm 2017

Tác giả Luận văn

Vũ Thị Hoa

MỤC LỤC

LỜI CẢM ƠN ............................................................................................................. i LỜI CAM ĐOAN ...................................................................................................... ii MỤC LỤC ................................................................................................................. iii DANH MỤC CÁC KÍ HIỆU, CÁC CHỮ VIẾT TẮT ............................................... v DANH MỤC CÁC HÌNH VẼ.................................................................................. vii MỞ ĐẦU ..................................................................................................................... 1 1. Lý do chọn đề tài ........................................................................................ 1 2. Mục đích nghiên cứu .................................................................................. 1 3. Nhiệm vụ nghiên cứu ................................................................................. 1 4. Phạm vi nghiên cứu và giới hạn ................................................................. 2 Phương pháp nghiên cứu ............................................................................ 2 5. 6. Giả thuyết khoa học ................................................................................... 2 Chương I: TỔNG QUAN VỀ RỦI RO DỰ ÁN PHẦN MỀM................................... 3 1.1 Quản lý rủi ro ................................................................................................ 3 1.1.1 Khái niệm về rủi ro ........................................................................................... 3 1.1.2 Rủi ro phần mềm .............................................................................................. 4 1.1.3 Quản lý rủi ro .................................................................................................... 5 1.2 Phân loại rủi ro trong các dự án phần mềm ................................................... 7 1.2.1 Nhóm các mối ràng buộc và cam kết ............................................................... 8 1.2.2 Nhóm về kỹ thuật phát triển phần mềm ........................................................... 8 1.2.3 Nhóm về môi trường phát triển dự án ............................................................ 10 1.3 Quy trình quản lý rủi ro ............................................................................... 11 1.3.1 Nhận diện rủi ro .............................................................................................. 12 1.3.2 Phân tích rủi ro và xếp hạng ........................................................................... 14 1.3.3 Kiểm soát rủi ro .............................................................................................. 16 1.3.4 Giám sát và điều chỉnh ................................................................................... 17 1.4. Giới thiệu về dự án xây dựng cổng thông tin điện tử Bộ GTVT ............... 17 1.4.1. Giới thiệu dự án ............................................................................................. 17 1.4.2. Các mục tiêu và yêu cầu ................................................................................ 18 1.5. Tiểu kết chương .......................................................................................... 19 Chương II: PHƯƠNG PHÁP QUẢN TRỊ RỦI RO HƯỚNG MỤC TIÊU .................... 20 2.1. Tổng quan về quản trị rủi ro hướng mục tiêu ............................................. 20 2.1.1. Mô hình quan hệ của quản trị rủi ro hướng mục tiêu .................................... 20 2.1.2.Mô hình lớp của quản trị rủi ro hướng mục tiêu: ........................................... 22 2.2. Mô hình quy trình và hoạt động thực hiện của phương pháp .................... 27

iii

2.2.1. Hoạt động 1: Khởi tạo ................................................................................... 28 2.2.2. Hoạt động 2: Xác định mục tiêu .................................................................... 30 2.2.3. Hoạt động 3: Xác định trở ngại ..................................................................... 31 2.2.4. Hoạt động 4: Đánh giá rủi ro ......................................................................... 33 2.2.5. Hoạt động 5: Quản lý và giám sát rủi ro........................................................ 34 2.2.6. Đặc tả rủi ro (Risk Specification) .................................................................. 37 2.3. Vai trò và trách nhiệm (Roles & Responsibilities) .................................... 37 2.3.1. Người quản lý rủi ro: ..................................................................................... 37 2.3.2. Chủ dự án: ..................................................................................................... 38 2.3.3. Người quản lý dự án: ..................................................................................... 38 2.3.4. Người tham gia dự án: ................................................................................... 39 2.3.5. Người sử dụng: .............................................................................................. 39 2.3. Ý tưởng áp dụng quản trị rủi ro hướng mục tiêu trong các dự án phần mềm ... 40 2.4. Kết luận chương 2 ...................................................................................... 40 Chương III. ỨNG DỤNG THỬ NGHIỆM PHƯƠNG PHÁP QUẢN TRỊ RỦI RO HƯỚNG MỤC TIÊU TRONG DỰ ÁN XÂY DỰNG CỔNG THÔNG TIN ĐIỆN TỬ BỘ GTVT ........................................................................................................... 41 3.1.Xây dựng giải pháp ứng dụng ..................................................................... 41 3.1.1. Mô hình hóa chức năng ................................................................................. 41 3.1.2.Thiết kế các thực thể ....................................................................................... 41 3.1.3. Thiết kế cơ sở dữ liệu .................................................................................... 42 3.1.4. Xây dựng các chức năng phần mềm .............................................................. 49 3.2. Sử dụng phần mềm áp dụng trong quản trị rủi ro xây dựng phần mềm cổng thông tin Bộ GTVT ................................................................................................ 51 3.3. Đánh giá và kết luận ................................................................................... 61 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI ......................................... 63 1. Kết luận ......................................................................................................... 63 2. Hướng phát triển của đề tài. .......................................................................... 63 TÀI LIỆU THAM KHẢO ......................................................................................... 65

DANH MỤC CÁC KÍ HIỆU, CÁC CHỮ VIẾT TẮT

CNTT Công nghệ thông tin

CMMi Capability Maturity Model Integration

SEI Software Engineering Institude Viện công nghệ phần mềm Hoa

Kỳ

PMP Project Management Professional

PMI Project Management InstituteViện quản trị dự án

SWOT Tập hợp viết tắt những chữ cái đầu tiên của các từ tiếng Anh:

Strengths (Điểm mạnh), Weaknesses (Điểm yếu), Opportunities

(Cơ hội) và Threats (Thách thức)

DANH MỤC CÁC BẢNG

Bảng 3.1 : Mô tả bảng người sử dụng Users ............................................................. 43 Bảng 3.2 : Mô tả bảng Projects ................................................................................. 43 Bảng 3.3 : Mô tả bảng Goal_Categories ................................................................... 44 Bảng 3.4: Mô tả bảng Goals ...................................................................................... 44 Bảng 3.5 : Mô tả bảng Risk_factors .......................................................................... 45 Bảng 3.6 : Mô tả bảng Risk_types ............................................................................ 45 Bảng 3.7: Mô tả bảng Risks ...................................................................................... 46 Bảng 3.8: Mô tả bảng Riskfactor-Riskevent ............................................................. 46 Bảng 3.9: Mô tả bảng riskfactor-goal ....................................................................... 47 Bảng 3.10 : Mô tả bảng Agents ................................................................................. 47 Bảng 3.11 : Mô tả bảng Methods .............................................................................. 48 Bảng 3.12 : Mô tả bảng Conflicts ............................................................................. 48 Bảng 3.13 : Mô tả bảng fitness.................................................................................. 49 Bảng 3.14 : Xây dựng và quản lý các mục tiêu của Dự án ....................................... 53 Bảng 3.15. Xác định và quản lý các yếu tố nguy cơ ................................................. 56 Bảng 3.16. Xây dụng các rủi ro có thể xảy ra trong quá trình thực hiện dự án ........ 58 Bảng 3.17. Xây dụng phương pháp xử lý rủi ro và theo dõi rủi ro ........................... 59

DANH MỤC CÁC HÌNH VẼ

Hình 1.1: Quy trình cơ bản quản lý rủi ro cơ bản ..................................................... 11 Hình 1.2: Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi ro .......... 12 Hình 1.3: Một số chiến lược và minh hoạ các phương pháp đối phó rủi ro thường gặp ............................................................................................................................. 16 Hình 2.1: Mô hình quan hệ của phương pháp quản trị rủi ro hướng mục tiêu [4] .... 20 Hình 2.2: Mô hình lớp của phương pháp quản trị rủi ro hướng mục tiêu [4] ........... 27 Hình 2.3: Mô hình của phương pháp quản trị rủi ro hướng mục tiêu [4] ................. 28 Hình 2.4: Chiến lược kiểm soát rủi ro ....................................................................... 36 Hình 3.1 Biểu đồ usecase sử dụng của hệ thống ....................................................... 41 Hình 3.2 Biểu đồ UML các thực thể trong một dự án .............................................. 42 Hình 3.3 Cơ sở dữ liệu – quan hệ giữa các bảng ...................................................... 42 Hình 3.4: Giao diện trang đăng nhập ........................................................................ 51 Hình 3.5: Giao diện trang quản lý rủi ro dự án ......................................................... 51

vii

MỞ ĐẦU

1. Lý do chọn đề tài

Trong một vài thập niên gần đây, đặc biệt là cuối thế kỉ 20 đầu thế kỉ 21, đã có

sự tăng lên mạnh mẽ của ứng dụng phần mềm. Do đó sự phức tạp trong phát triển

phần mềm cũng tăng đáng kể trong những năm này. Vấn đề quản lí bao gồm các

vấn đề về cấu trúc dự án, tài nguyên dự án, phương pháp quy hoạch và quản lí rủi ro

chưa đầy đủ. Như vậy rủi ro trong các dự án phần mềm là không thể tránh khỏi.

Mọi rủi ro đều tạo ra vấn đề, đều gây ảnh hưởng xấu tới các dự án phần mềm, do đó

những kỹ sư phần mềm phải có những biện pháp nhận diện rủi ro hiệu quả, thẩm

định xác suất thực hiện, tác động nếu nó xuất hiện và giải quyết nó một cách hiệu

quả để đạt được phần mềm tốt theo yêu cầu của khách hàng. Phương pháp quản trị

rủi ro hướng mục tiêu (Goal-Driven Approach) gần đây được sử dụng như là một

hướng tiếp cận mới trong quản trị rủi ro của các dự án phần mềm.

Luận văn sẽ tìm hiểu về phương pháp này và thử nghiệm ứng dụng trong Dự

án xây dựng cổng thông tin điện tử Bộ GTVT.

2. Mục đích nghiên cứu

Mục đích chính của nghiên cứu này là để xác định rủi ro trong các hoạt động

có ảnh hưởng đến chi phí dự án và thời gian thực hiện dự án. Phân tích rủi ro sẽ

được tiến hành thông qua phương pháp quản trị rủi ro hướng mục tiêu.

Mục đích chính của nghiên cứu này là tìm hiểu về quản trị rủi ro, tập trung vào

phương pháp quản trị rủi ro hướng mục tiêu trong các dự án phát triển phần mềm.

Xây dựng giải pháp ứng dụng phương pháp quản trị rủi ro hướng mục tiêu trong

quá trình thực hiện dự án xây dựng cổng thông tin điện tử Bộ GTVT, thử nghiệm và

đánh giá kết quả.

3. Nhiệm vụ nghiên cứu

Nhiệm vụ thứ nhất: Tìm hiểu về quản trị rủi ro trong dự án phần mềm và dự án

xây dựng cổng thông tin điện tử Bộ GTVT, nơi tôi công tác.

Nhiệm vụ thứ hai: Tập trung vào phương pháp quản trị rủi ro hướng mục tiêu

trong các dự án phát triển phần mềm

Nhiệm vụ thứ ba: Xây dựng giải pháp ứng dụng phương pháp quản trị rủi ro

hướng mục tiêu trong quá trình thực hiện dự án xây dựng cổng thông tin điện tử Bộ

GTVT (lấy một mô-đun thực tế), thử nghiệm và đánh giá kết quả.

4. Phạm vi nghiên cứu và giới hạn

Phạm vi nghiên cứu dừng lại ở mức độ tìm hiểu lý thuyết về phương pháp

quản trị rủi ro hướng mục tiêu và thử nghiệm áp dụng trong Dự án xây dựng cổng

thông tin điện tử Bộ GTVT cho một chức năng cụ thể. Thông tin có thể thay đổi

trong quá trình dự án, nhưng các số liệu mô hình hóa được tôi giả định trên các ý

kiến chuyên gia và kinh nghiệm bản thân nên không thể mở rộng sự thay đổi hoặc

tác động của nó tới dự án. Các số liệu và kết quả mang tính chất khuyến cáo cho các

chuyên gia CNTT tham gia vào quá trình thực hiện dự án.

5. Phương pháp nghiên cứu

Nghiên cứu sẽ được tiến hành thông qua nghiên cứu mô hình lý thuyết của

phương pháp quản trị rủi ro hướng mục tiêu: Tập hợp kiến thức lý thuyết, mô hình

hóa, xây dựng phần mềm minh họa.

Phần mềm mô phỏng và tiếp cận định tính cũng sẽ được sử dụng qua ý kiến

chuyên gia tính để đề xuất các khuyến cáo cho quản lý rủi ro.

6. Giả thuyết khoa học

Về lý thuyết:

- Tổng hợp các thông tin liên quan từ các nguồn: Các tạp chí khoa học chuyên

ngành trong và ngoài nước, internet, lựa chọn các cách tiếp cận đã được áp dụng

thành công.

- Trao đổi với thầy hướng dẫn và các chuyên gia tại Trung tâm tin học Bộ

Giao thông vận tải.

Về thực nghiệm:

- Tìm hiểu một số dự án cụ thể và nghiên cứu rủi ro trong dự án.

- Lập trình thử nghiệm mô hình để kiểm tra, đánh giá độ chính xác.

- Thử nghiệm trên các số liệu lấy từ các chuyên gia trong quá trình thực hiện

dự án thực tế.

Chương I: TỔNG QUAN VỀ RỦI RO DỰ ÁN PHẦN MỀM

Trong một vài thập niên gần đây đặc biệt là cuối thế kỷ 20 đầu thế kỷ 21 đã có

sự tăng lên mạnh mẽ của ngành tự động hóa. Các ngành tự động hoá này căn bản lại

phụ thuộc vào các phần mềm chức năng, do đó sự phức tạp trong phát triển phần

mềm cũng tăng đáng kể trong những năm này. Mac Manus đã nhận định 65% dẫn

đến thất bại của dự án là do những vấn đề trong quản lý, 35% là những vấn đề về

công nghệ. Vấn đề quản lý bao gồm các vấn đề với cấu trúc của dự án, tài nguyên

dự án, quy hoạch phương pháp và quản lý rủi ro chưa đầy đủ. Các vấn đề kỹ thuật

bao gồm thiết kế phần mềm nghèo nàn, không tuân thủ các yêu cầu phần mềm, kỹ

thuật đánh giá và phát triển không đúng.

Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sản xuất, kinh doanh và đời

sống và dự án phần mềm cũng không ngoại lệ. Tuy nhiên, với đặc thù riêng của

mình, nhận diện và kiểm soát rủi ro trong các dự án phần mềm là điều không hề đơn

giản. Mọi rủi ro đều tạo ra vấn đề, đều gây ảnh hưởng xấu tới các dự án phần mềm,

do đó những kỹ sư phần mềm phải có những biện pháp nhận diện rủi ro hiệu quả,

thẩm định xác suất xuất hiện, tác động nếu nó xuất hiện và giải quyết nó một cách

hiệu quả để đạt được phần mềm tốt theo yêu cầu của khách hàng.

1.1 Quản lý rủi ro

1.1.1 Khái niệm về rủi ro

Thực tế nghiên cứu các tài liệu cho thấy, có rất nhiều định nghĩa về rủi ro và

đến nay vẫn chưa có một khái niệm thống nhất nào về rủi ro. Tùy theo từng quan

điểm, các trường phái khác nhau, các tác giả khác nhau lại đưa ra những định nghĩa

khác nhau. Nhìn chung có thể chia các khái niệm rủi ro làm hai trường phái là

trường phái truyền thống và trường phái hiện đại. Trường phái đầu tiên cho rằng rủi

ro là những thiệt hại, mất mát, nguy hiểm hoặc các yếu tố liên quan đến nguy hiểm,

khó khăn hoặc điều không chắc chắn (uncertainty) có thể xảy ra cho con người.

Trường phái thứ hai quan niệm rủi ro là sự bất trắc có thể đo lường được, vừa mang

tính tích cực lẫn tiêu cực. Rủi ro có thể mang đến sự tổn thất nhưng có thể mang lại

nhưng lợi ích, cơ hội. Ví dụ, việc xảy ra rủi ro giúp con người nhận thức được

những rủi ro có thể xảy ra, nghiên cứu rủi ro và tìm ra được những biện pháp để đề

phòng chúng xuất hiện. Rủi ro xuất hiện khi tồn tại đồng thời hai yếu tố cơ bản yếu

tố gây rủi ro và đối tượng chịu tác động, ảnh hưởng. Phạm vi nghiên cứu về rủi ro

cũng khá phong phú và đa dạng, vì vậy ở đây ta chỉ xét đến rủi ro thường xuất hiện

ở khía cạnh kỹ thuật trong các dự án phần mềm.

- Rủi ro có hai thuộc tính chủ yếu là xác suất rủi ro sẽ xuất hiện và tác động

của rủi ro nếu nó xuất hiện.

+ Xác suất rủi ro sẽ xuất hiện: Chúng ta có thể dùng tỉ lệ 0 – 8 để mô tả xác

suất của rủi ro. Rủi ro có xác suất 0 được gọi là không có cơ hội xuất hiện. Rủi ro có

xác suất 8 được gọi là chắc chắn xảy ra. Xác suất trong khoảng 0 – 8 thì rủi ro có cơ

hội xuất hiện.

+ Tác động của rủi ro nếu nó xuất hiện: Chúng ta có thể dùng thang 0-8 để mô

tả tác động của rủi ro. Rủi ro với tác động 0 được gọi là không có tác động. Rủi ro

với tác động 8 được gọi là đình chỉ (nguy hiểm nghiêm trọng dẫn đến dự án không

thực hiện được).

1.1.2 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 dọa

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ãng 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).

Thứ hai, đe dọa 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ầm mềm.

+ Sự đe dọa cuối cùng được cụ thể hóa 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 tác động chủ ý của người tấn công, đe

dọa này gọi là rủi ro bảo mật phần mềm.

1.1.3 Quản lý rủi ro

- Các bộ mô hình tiêu chuẩn nổi tiếng được ứng dụng nhiều trong dự án phần

mềm:

Trong các dự án công nghệ thông tin, tỉ lệ thành công theo nghĩa đạt được yêu

cầu chất lượng, đúng hạn và không vượt chi là rất không cao, nguyên nhân chủ yếu

là do không có, hoặc thực hiện không tốt việc phòng ngừa và xử lý các nguy cơ dẫn

đến thất bại của một dự án. Như vậy quản lý 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ả hai bộ mô hình 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) đề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. Một cách hiểu

đơn giản, quản lý rủi ro là cách để quản lý các rủi ro, để làm giảm những tác động

của những sự kiện không mong muốn phát sinh trong dự án [7,9,11].

-Tầm quan trọng của quản lý rủi ro:

Quản lý rủi ro là một nghệ thuật và những nhận biết khoa học, là nhiệm vụ và

là sự đối phó rủi ro thông qua hoạt động của dự án và những mục tiêu đòi hỏi quan

trọng nhất của dự án. Quản lý rủi ro thường không được chú ý nhiều trong các dự

án, nhưng nó lại giúp cải thiện được sự thành công của dự án trong việc giúp chọn

lựa những dự án tốt, xác định phạm vi dự án và phát triển những ước tính có tính

thực tế.

-Mục đích của quản lý rủi ro trong kỹ nghệ phần mềm:

+ Quản lý rủi ro giúp cho một dự án tránh khỏi bị thất bại như không hoàn

thành dự án như kế hoạch đã định, vượt quá ngân sách và không đáp ứng được sự

mong đợi của khách hàng. Quản lý rủi ro tìm kiếm và xem xét từ các góc cạnh khác

nhau trong các dự án để đảm bảo rằng những mối đe dọa cho các dự án được xác

định và phân tích, tiến hành các chiến lược thích hợp để giảm nhẹ và khống chế rủi

ro. Chức năng chính của quản lý rủi ro là đoán nhận được tất cả những rủi ro có khả

năng ảnh hưởng đến một dự án, đánh giá mức độ nghiêm trọng và hậu quả, sau đó

xác định các giải pháp tùy theo tính chất của các rủi ro. Giảm thiểu tối đa các yếu tố

bất ngờ và các vấn đề không mong đợi phát sinh trong suốt quá trình thực hiện của

dự án, bằng cách thiết lập ra các kế hoạch cho các tình huống có thể xảy ra. Những

kế hoạch này sẽ giảm thiểu tối đa những tình huống có thể dẫn tới các sản phẩm

lệch lạc hoặc có thể phá hủy toàn bộ dự án.

+ Quản lý rủi ro làm giảm tối thiểu khả năng rủi ro, trong khi đó tăng tối đa

những cơ hội tiềm năng.

Quản lý rủi ro đã xuất hiện trong nhiều thập kỷ. Tuy nhiên chỉ vào khoảng nửa

cuối thập kỷ trước nó mới thật sự trở lên quan trọng đối với cộng đồng phần mềm.

Trong những năm đầu của thế kỷ trước, các dự án phần mềm chỉ được áp dụng quản

lý rủi ro bằng các cách tiếp cận bộc phát, không hề theo một phương pháp hệ thống

nào. Tuy nhiên với sự phức tạp đang được tăng lên trong việc phát triển phần mềm,

nhiều ngành công nghiệp đã thấy được sự quan trọng của quản lý rủi ro. Trước khi

áp dụng bất cứ một quá trình quản lý rủi ro nào, các thành viên trong nhóm thực

hiện dự án nên nắm được rõ ràng về các hậu quả sau này của các rủi ro trong dự án

của họ như:

-Sự mất mát sẽ phát sinh nếu xuất hiện rủi ro: sự mất mát trong dự án phần

mềm có thể kể đến như lợi nhuận, thị phần, khách hàng.

-Tính nghiêm trọng của sự mất mát.

-Tính lâu dài của các rủi ro.

-Những mô hình quản lý rủi ro phần mềm phổ biến: Đã có một vài cách tiếp

cận quản lý rủi ro phần mềm được đề xuất trong quá khứ. Hầu hết là đánh giá rủi ro

trong tất cả các giai đoạn phát triển phần mềm. Kết quả là trong những cách tiếp cận

đó, các mô hình quản lý rủi ro đã được áp dụng một cách có kỷ luật. Đó là những

cách tiếp cận sau [4]:

+ Mô hình quản lý rủi ro của Boehm (Win-Win).

+ Mô hình quản lý rủi ro phần mềm của SEI.

Những đóng góp nền tảng của Boehm: Boehm đã đề xuất một mô hình phát

triển phần mềm là điều khiển rủi ro. Điểm mạnh trong mô hình này là đã quy công

việc vào thành một mô hình xoắn ốc, nhiều rủi ro được loại bỏ tại những giai đoạn

sớm nhất thay vì sẽ gặp phải những rào cản dự án ở những giai đoạn sau. Boehm đã

mở rộng mô hình xoắn ốc của ông bằng cách sử dụng lý thuyết mô hình win-win,

với mục tiêu đáp ứng các mục đích và mối quan tâm của các bên liên quan. Năm

1991, Boehm cũng đề xuất ra một khung quản lý rủi ro, giúp tìm ra được những

nguồn rủi ro chính, phân tích và phân giải chúng.

Tiếp cận quản lý rủi ro phần mềm của SEI [11]: SEI đã cung cấp một khuôn

khổ quản lý rủi ro toàn diện bao gồm trong ba nhóm: Đánh giá rủi ro phần mềm,

quản lý rủi ro liên tục, nhóm quản lý rủi ro.

- Đánh giá rủi ro phần mềm liên quan đến nhận biết, phân tích, liên lạc và các

chiến lược làm giảm nhẹ quản lý rủi ro phần mềm. Phân loại rủi ro bao gồm rủi ro

trong yêu cầu, rủi ro trong thiết kế, rủi ro viết code và kiểm thử, rủi ro hợp đồng…

- Quản lý rủi ro liên tục được tiếp cận trên nguyên tắc cung cấp các tiến trình,

phương thức và công cụ liên tục cho quá trình quản lý rủi ro trong tất cả các giai

đoạn của vòng đời phần mềm.

- Nhóm quản lý rủi ro liên quan với sự phát triển của các phương pháp luận,

các chương trình và các công cụ trong sự phát triển mối quan hệ giữa khách hàng và

nhà cung cấp.

Ba nhóm trên đều có tác dụng tương hỗ với nhau, chẳng hạn một nhóm được

định hướng tiếp cận cho quản lý rủi ro cũng có thể hỗ trợ được cho quản lý rủi ro

liên tục.

1.2 Phân loại rủi ro trong các dự án phần mềm

Trong thực tế, khả năng xuất hiện cũng như tác hại của các rủi ro ở những dự

án khác nhau là hoàn toàn khác nhau. Có những rủi ro xuất hiện trong rất nhiều dự

án, nhưng tác hại gây ra lại không lớn, hoặc chỉ lớn trong vài dự án. Ngược lại, một

số rủi ro chỉ xảy ra trong những điều kiện hoặc dự án nhất định, nhưng tác hại do

chúng gây ra là rất lớn, hoặc tác hại có thể dự đoán và ngăn ngừa được. Có những

rủi ro có thể tránh được nếu ta phát hiện sớm, có những rủi ro buộc phải chấp nhận

và phải có hành động đối phó hoặc khắc phục. Các rủi ro rất đa dạng và chúng xuất

phát từ nhiều nguồn khác nhau, từ bên ngoài lẫn từ nội bộ dự án hoặc tổ chức. Theo

phân tích của Viện công nghệ phần mềm Mỹ SEI, thông thường các rủi ro xuất phát

hoặc phân loại từ ba nhóm sau [11]:

- Nhóm các mối ràng buộc và cam kết,

- Nhóm về kỹ thuật phát triển phần mềm,

- Nhóm về môi trường phát triển dự án.

1.2.1 Nhóm các mối ràng buộc và cam kết

Bao gồm các rủi ro liên quan đến các mối ràng buộc bên trong lẫn bên ngoài.

Các rủi ro thường xoay quanh các vấn đề sau: Về nguồn lực, các mối ràng buộc bên

ngoài tác động đến thời gian, nhân lực, ngân sách hoặc phương tiện tài trợ cho dự

án. Về hợp đồng, các điều khoản ràng buộc đã cam kết trong hợp đồng giữa hai bên,

thời hạn thực hiện dự án, các yêu cầu nghiệm thu, các yêu cầu về phạm vi dự án và

các thay đổi. Về đối tác, bao gồm điều cam kết và ràng buộc khác đối với khách

hàng, thầu phụ, ban giám đốc. Một số rủi ro thường gặp trong thực tế bao gồm:

Thời gian thực hiện dự án quá gấp: Thời hạn thực hiện và bàn giao sản phẩm

quá ngắn, xuất hiện ngay từ đầu dự án, hoặc có khả năng xuất hiện cao trong lúc

thực thi. Các rủi ro này liên quan đến các điều cam kết cấp cao, hoặc do quá thiếu

dữ liệu để ước lượng, hoặc do dự án sử dụng công nghệ mới, độ phức tạp cao do đó

rủi ro hầu như được “nhìn thấy” trước.

Thiếu thời gian cho kiểm định: Kiểm thử phần mềm là một khâu khá quan

trọng và chiếm nhiều thời gian, đặc biệt ở các giai đoạn cuối. Tuy nhiên, trong

nhiều dự án, thời lượng và nhân lực cho giai đoạn này lại khá hạn chế. Các yếu tố

dẫn đến rủi ro này thường liên quan đến tính chất đặc thù của dự án như khả năng

sinh lỗi cao, hoặc do dự án có yêu cầu thay đổi quá nhiều.

1.2.2 Nhóm về kỹ thuật phát triển phần mềm

Bao gồm các rủi ro liên quan đến kỹ thuật phát triển phần mềm. Các rủi ro có

thể liên quan đến các chặng hay nhóm tác vụ liên quan đến kỹ thuật của dự án như

công nghệ mới, yêu cầu không rõ ràng, thiết kế không tuân thủ các tiêu chuẩn, quy

trình của khách hàng khó hiểu, phức tạp, hệ thống cũ thiếu tài liệu, thiếu công cụ

kiểm định theo chuẩn mực…Các rủi ro thường xoay quanh các vấn đề liên quan đến

yêu cầu của dự án: Thường gây ra sự hiểu lầm giữa hai bên, hoặc có sự cách biệt

lớn so với những ước lượng từ ban đầu; thiết kế. Điều này xảy ra khi thiết kế không

phản ánh đúng yêu cầu của phần mềm, hoặc phần mềm vẫn chạy nhưng kém hiệu

quả, không phản ánh đúng các mối ràng buộc khi sử dụng phần mềm. Rủi ro liên

quan đến kỹ thuật cũng phát sinh khi việc phát triển dự án không phản ánh đúng các

thiết kế, và chương trình chứa đựng nhiều lỗi nội tại ở mức đơn vị. Ở khâu tích hợp

và kiểm định, sản phẩm chứa đựng nhiều sai sót khi tích hợp, hoặc chứa đựng lỗi

tiềm ẩn do kiểm định chưa hết cũng dẫn đến những rủi ro về kỹ thuật. Cuối cùng là

các yêu cầu đặc biệt khác, thường là về tính an toàn của phần mềm, tính ổn định

trong môi trường vận hành thực, bảo mật dữ liệu. Minh họa cho nhóm này, một số

rủi ro thường gặp trong thực tế bao gồm [11]:

Yêu cầu khó hiểu, nhiều thay đổi: Rủi ro này bắt gặp trong rất nhiều dự án, và

là một trong những nguyên nhân phổ biến nhất làm cho dự án kéo dài và thậm chí

thất bại. Rủi ro liên quan đến nhiều trạng thái dẫn đến việc hiểu sai, bỏ sót hoặc bị

quá tải các yêu cầu và thay đổi củadự án, thông thường bao gồm các yêu cầu:

-Không đủ, không rõ ràng, văn phong trừu tượng, thiếu dữ liệu.

-Mâu thuẫn nhau, thiếu chặt chẽ hoặc qúa sơ sài.

-Thay đổi quá nhiều và thường xuyên (hằng ngày, hằng tuần).

-Thay đổi sát lúc hoàn thành dự án.

-Tài liệu yêu cầu quá đồ sộ, do nhiều người tham gia.

Kiểm thử mức đơn vị (unit test) nghèo nàn: Rủi ro này khá phổ biến trong

nhiều dự án. Kiểm định mức đơn vị phải do lập trình viên (developer) thực hiện

trước khi bàn giao sản phẩm để tích hợp và kiểm định mức hệ thống (system test).

Công việc này đòi hỏi thời gian, do đó nếu không giám sát chặt chẽ, nó thường bị

bỏ qua hoặc làm chiếu lệ. Rủi ro này sẽ dẫn đến những lỗi phần mềm tiềm ẩn rất

khó phát hiện và chỉnh sửa khi phần mềm đi vào hoạt động, hoặc nếu chỉnh sửa sẽ

tốn rất nhiều công sức.

1.2.3 Nhóm về môi trường phát triển dự án

Bao gồm các rủi ro liên quan đến các điều kiện hỗ trợ và bảo đảm dự án được

thực thi tốt. Chẳng hạn, các rủi ro liên quan đến bất đồng ngôn ngữ, môi trường

phát triển với kỹ thuật quá mới, phong cách quản lý không phù hợp, môi trường và

công cụ truyền thông kém, thiếu phần mềm do bị ràng buộc về vấn đề bản quyền,

môi trường làm việc chật chội, nóng bức, thiếu hệ thống backup dữ liệu và nguồn

điện dự phòng…

Các rủi ro thường liên quan đến bốn vấn đề sau: Thứ nhất là quy trình, bao

gồm kế hoạch phát triển dự án, tài liệu, sự ràng buộc tuân thủ quy trình, truyền

thông giữa các nhóm, phương pháp phát triển dự án, khả năng của trưởng dự án, sự

giám sát của cấp trên hoặc của khách hàng; Thứ hai là kỹ thuật, dùng để phát triển

dự án, ngôn ngữ, phần mềm có bản quyền, các bộ giả lập, biên dịch, hệ thống máy

tính…, công nghệ mới; Thứ ba là môi trường làm việc như văn hóa, thói quen, thái

độ, tinh thần làm việc, sự hợp tác với nhau của nhân viên. Rủi ro về môi trường,

luật pháp, sự ổn định về chính trị; và thứ tư là nhân lực như trình độ, kỹ năng và

kinh nghiệm của nguồn lực, bất đồng ngôn ngữ, các xung đột. Minh họa cho nhóm

này, một số rủi ro thường gặp trong thực tế bao gồm:

Nhân viên thiếu kiến thức và kinh nghiệm: Rủi ro này liên quan đến vấn đề

trình độ, kiến thức và kinh nghiệm của nhân viên dự án yếu kém (nhất là nhân viên

mới), không đáp ứng được yêu cầu khắt khe của dự án, đặc biệt là các dự án sử

dụng công nghệ và kỹ thuật mới, độ phức tạp cao, dự án được phát triển dựa trên hệ

thống đã có sẵn, đòi hỏi nhân viên phải am hiểu.

Rào cản ngôn ngữ: Rủi ro về rào cản ngôn ngữ mang tính tự nhiên và xảy ra

trong hầu hết cácdự án làm cho đối tác nước ngoài. Trong thực tế, rủi ro về tiếng

Anh là phổ biến nhưng các dự án có thể khắc phục được do hầu hết kỹ sư đều có thể

làm việc với tài liệu tiếng Anh, một số khó khăn lớn nhất thường chỉ liên quan đến

giao tiếp trực tiếp. Ngược lại, rủi ro về tiếng Nhật và Pháp được lưu ý đặc biệt vì

mức độ nghiêm trọng của chúng. Hầu hết kỹ sư không thể hiểu và làm việc trực tiếp

với tiếng Nhật và Pháp, đều phải qua trung gian là các kỹ sư cầu nối (Bridge

Engineer).

1.3 Quy trình quản lý rủi ro

Nhận diện và kiểm soát tốt rủi ro chỉ bằng những kỹ năng và kinh nghiệm cá

nhân không thì 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ơ quản lý rủi ro bao gồm các bước chính được trình bày

ở Hình 1.1.

Ở mức chi tiết hơn, quy trình quản lý rủi ro bao gồm các bước cùng với trình

tự xử lý và mối quan hệ giữa chúng như trình bày ở Hình 1.2

Hình 1.1: Quy trình cơ bản quản lý rủi ro cơ bản

Hình 1.2: Mối quan hệ và trình tự trong quy trình kiểm soát rủi ro [3]

1.3.1 Nhận diện rủi ro

Nhận diện rủi ro là quy trình quyết định những rủi ro nào có thể ảnh hưởng đến

dự án và tài liệu hóa các đặc điểm của chúng. Nhận diện rủi ro liên quan đến việc nhận

diện các rủi ro có thể ảnh hưởng đến dự án và tài liệu hóa đặc điểm của chúng.

Những người tham gia trong việc nhận diện rủi ro nói chung có thể bao gồm

những người sau đây: đội dự án, đội quản lý rủi ro, chuyên gia vấn đề từ các bộ

phận khác của công ty, khách hàng, người dùng cuối, những người quản lý dự án

khác, các bên liên quan, và các chuyên gia từ bên ngoài.

Phát triển các ứng phó rủi ro thường đơn giản và hiệu quả và thậm chí có thể

thực hiện được khi các rủi ro được nhận diện. Tuy nhiên, xác định được chính xác

các nguồn có khả năng phát sinh rủi ro là điều không dễ dàng. Thông thường rủi ro

xuất hiện từ các nguồn sau:

-Ngân sách - nguồn tài trợ cho dự án.

-Thời gian thực hiện dự án.

-Thay đổi về phạm vi và yêu cầu dự án.

-Khó khăn về kỹ thuật.

-Hợp đồng giữa các bên.

-Môi trường, luật pháp, chính trị, văn hoá.

• Kỹ thuật nhận diện rủi ro

Để nhận diện được rủi ro có nhiều kỹ thuật được áp dụng. Các kỹ thuật được

sử dụng rộng rãi bao gồm:

Danh sách kiểm tra (checklist): Các danh sách kiểm tra để nhận diện rủi ro có

thể được phát triển dựa trên các thông tin lịch sử và kiến thức đã được tích lũy từ

các dự án tương tự trước đây và từ các nguồn thông tin khác. Một lợi thế của việc

sử dụng một danh sách kiểm tra là nhận diện rủi ro là nhanh chóng và đơn giản.

Một nhược điểm là nó không thể xây dựng một danh sách kiểm tra đầy đủ các rủi

ro, và người dùng có thể bị giới hạn hiệu quả ở những hạng mục trong danh sách.

Nên cẩn thận để khám phá các mục không xuất hiện trên một danh sách kiểm tra

tiêu chuẩn nếu chúng có thể có liên quan đến các dự án cụ thể. Danh sách kiểm tra

cần ghi rõ từng mục tất cả các loại rủi ro có thể đối với dự án Việc rà soát lại danh

sách kiểm tra như là một bước chính thức của mọi thủ tục kết thúc dự án là rất quan

trọng nhằm cải thiện danh sách các rủi ro tiềm ẩn, và cải thiện các mô tả về rủi ro.

Kỹ thuật này có thể tham khảo các kinh nghiệm từ bên ngoài, một trong những

tham khảo tốt nhất theo cách này là sử dụng bảng phân loại và liệt kê các rủi ro

thường gặp của viện kỹ thuật phần mềm Hoa Kỳ (SEI).

Sự động não: Động não có lẽ là kỹ thuật nhận diện rủi ro được sử dụng thường

xuyên nhất. Mục đích là để có được một danh sách toàn diện để có thể được giải

quyết sau đó trong quá trình phân tích rủi ro định tính và định lượng. Đội dự án

thường xuyên thực hiện động não, mặc dù một nhóm các chuyên gia đa ngành có

thể thực hiện kỹ thuật này. Dưới sự lãnh đạo của một người điều hành, những người

khác đưa ra những ý tưởng về rủi ro của dự án. Nguồn gốc rủi ro được nhận diện

trong phạm vi rộng và gửi cho tất cả để xem xét trong cuộc họp. Rủi ro này sau đó

được phân loại, và định nghĩa của chúng được đưa ra chính xác hơn.

Phán đoán chuyên gia: Rủi ro có thể được nhận diện trực tiếp bởi các chuyên

gia có kinh nghiệm phù hợp với các dự án hoặc các lĩnh vực kinh doanh tương ứng.

Các chuyên gia này cần được xác định bởi người quản lý dự án và mời đến để xem

xét tất cả các khía cạnh của dự án và đề xuất rủi ro có thể dựa vào kinh nghiệm và

lĩnh vực chuyên môn của họ trước đó. Các đánh giá có tính chất thành kiến của các

chuyên gia nên được đưa vào một bảng kê trong quá trình này.

Phân tích SWOT: Kỹ thuật này kiểm tra dự án từ mỗi điểm mạnh, điểm yếu, các

cơ hội và các khía cạnh đe dọa (SWOT) để tăng bề rộng của các rủi ro nhận diện được

bằng các rủi ro phát sinh nội bộ. Kỹ thuật bắt đầu với việc xác định các điểm mạnh và

điểm yếu của tổ chức, tập trung vào cả dự án, tổ chức hay lĩnh vực kinh doanh nói

chung. Phân tích SWOT sau đó định nghĩa bất kỳ cơ hội nào cho dự án có được từ

những điểm mạnh của tổ chức và bất kỳ mối đe dọa phát sinh này từ điểm yếu của tổ

chức. Phân tích cũng kiểm tra mức độ mà các điểm mạnh của tổ chức bù đắp cho các

mối đe dọa, cũng như xác định các cơ hội để khắc phục điểm yếu.

Phân tích các giả thiết: Mỗi dự án được hình thành và phát triển dựa trên một

tập hợp các giả thiết, kịch bản, hoặc giả định. Phân tích giả thiết là một kỹ thuật

khám phá tính hợp lệ của các giả thiết. Nó nhận diện rủi ro đối với các dự án từ

những giả thiết không chính xác, không thống nhất, hoặc không đầy đủ.

Tập các bài học kinh nghiệm: Yếu tố rủi ro được xác định và phải đối mặt

trong suốt vòng đời của dự án nên được bao gồm trong các bài học kinh nghiệm.

Chúng ta cần tham khảo các tập bài học kinh nghiệm trong tổ chức của chúng ta khi

lên kế hoạch một dự án. Chúng ta cũng nên trao đổi với các nhà quản lý dự án, các

kiến trúc sư phần mềm, các nhà lãnh đạo nhóm, các thành viên dự án và khách hàng

(trong phạm vi có thể) đề hiểu được các yếu tố rủi ro xã hội và chính trị mà có thể

không được ghi trong các tập bài học kinh nghiệm.

1.3.2 Phân tích rủi ro và xếp hạng

Phân tích rủi ro liên quan đến việc đánh giá xác suất, tác động tiềm tàng và

khung thời gian có khả năng xuất hiện của các yếu tố được xác định. Ưu tiên xếp

hạng các yếu tố rủi ro của xác suất, tác động và khung thời gian khi một vấn đề tiềm

năng có thể trở thành một vấn đề thực sự. Chúng ta có thể thực hiện phân tích rủi ro

bằng cách gán giá trị số để xác suất và tác động tiềm tàng đối với từng yếu tố rủi ro

được xác định.

• Phân tích xác suất xuất hiện của rủi ro:

Có 4 mức để đo lường khả năng xuất hiện của rủi ro, mỗi mức được gán với

một giá trị số để có thể ước lượng sự quan trọng của nó:

6 - Thường xuyên: khả năng xuất hiện rủi ro rất cao, xuất hiện trong hầu hết

dự án.

4 - Hay xảy ra: khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều dự án.

2 - Đôi khi: khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở một số ít dự

án.

1 - Hiếm khi: khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện

nhất định.

•Phân tích mức tác động của rủi ro:

Có 4 mức tác động của rủi ro, mỗi mức độ được gán với 1 giá trị số để có thể

ước lượng sự tác động của nó:

8 - Trầm trọng: Có khả năng làm dự án thất bại rất cao.

6 - Quan trọng: Gây khó khăn lớn và làm dự án không đạt được các mục tiêu.

2 - Vừa phải: Gây khó khăn cho dự án, ảnh hưởng việc đạt các mục tiêu của dự án.

1 - Không đáng kể: Gây khó khăn không đáng kể.

• Phân tích thời điểm xuất hiện rủi ro:

Có 4 mức để ước lượng thời điểm rủi ro xuất hiện, mỗi mức được gán với một

giá trị số để có thể ước lượng sự tác động của nó.

6 - Ngay lập tức: Rủi ro xuất hiện gần như tức khắc.

4 - Rất gần: Rủi ro sẽ xuất hiện trong thời điểm rất gần thời điểm phân tích.

2 - Sắp xảy ra: Rủi ro sẽ xuất hiện trong tương lai gần.

1 - Rất lâu: Rủi ro sẽ xuất hiện trong tương lai xa hoặc chưa định được.

Các giá trị số cho trên chỉ mang tính tham khảo và minh họa, giá trị của chúng

được định tùy tổ chức, tùy dự án.

1.3.3 Kiểm soát rủi ro

Kiểm soát rủi ro bắt đầu với việc chọn lựa chiến lược và phương pháp đối phó

rủi ro. Trong thực tế, các chiến lược phổ biến bao gồm [9]:

Hình 1.3: Một số chiến lược và minh hoạ các phương pháp đối phó rủi ro thường gặp [3]

Tránh né: Dùng “đi đường khác” để né tránh rủi ro, đường đi mới có thể không có

rủi ro, có rủi ro nhẹ hơn, hoặc chi phí đối phó rủi ro thấp hơn. Chẳng hạn như:

-Thay đổi phương pháp, công cụ thực hiện, thay đổi con người.

-Thương lượng với khách hàng (hoặc nội bộ) để thay đổi mục tiêu.

Chuyển giao: Giảm thiểu rủi ro bằng cách chia sẻ tác hại khi chúng xảy ra.

Chẳng hạn:

-Đề nghị với khách hàng chấp nhận và chia sẻ rủi ro (tăng thời gian, chi phí).

-Báo cáo ban lãnh đạo để chấp nhận tác động và chi phí đối với rủi ro

-Mua bảo hiểm để chia sẻ chi phí khi rủi ro xảy ra.

Giảm nhẹ: Thực thi các biện pháp để giảm thiểu khả năng xảy ra rủi ro hoặc

giảm thiểu tác động và chi phí khắc phục rủi ro nếu nó xảy ra. Chẳng hạn:

-Cảnh báo và triệt tiêu các yếu tố làm cho rủi ro xuất hiện.

-Điều chỉnh các yếu tố có liên quan theo dây chuyền để rủi ro xảy ra sẽ ít có

tác động.

Chấp nhận: Đành chấp nhận “sống chung” với rủi ro trong trường hợp chi phí

loại bỏ, phòng tránh, làm nhẹ rủi ro quá lớn (lớn hơn chi phí khắc phục tác hại), hoặc

tác hại của rủi ro nếu xảy ra là nhỏ hay cực kỳ thấp. Kế hoạch đối phó có thể là:

-Thu thập hoặc mua thông tin để có kế hoạch kiểm soát tốt hơn.

-Lập kế hoạch khắc phục tác hại khi rủi ro xảy ra.

1.3.4 Giám sát và điều chỉnh

Bao gồm hoạt động giám sát để đảm bảo các chiến lược đối phó rủi ro được

lên kế hoạch và thực thi chặt chẽ. Việc giám sát cũng nhằm mục đích điều chỉnh các

chiến lược hoặc kế hoạch đối phó nếu chúng tỏ ra không hiệu quả, không khả thi,

tốn quá nhiều ngân sách, hoặc để đáp ứng với những rủi ro mới xuất hiện, hoặc sự

biến tướng của rủi ro đã được nhận diện trước đó.

Kết quả giám sát có thể được báo cáo định kỳ đến tất cả những người có liên

quan, đến quản lý cấp cao, hoặc đến khách hàng nếu cần thiết.

Trong thực tế, do các yếu tố liên quan đến dự án thay đổi liên tục, chu trình

quản lý rủi ro không đi theo đường thẳng mà được lặp lại và điều chỉnh liên tục giữa

các chặng. Các rủi ro liên tục được điều chỉnh hoặc nhận diện mới, do đó các chiến

lược và kế hoạch đối phó cũng luôn được thay đổi để đảm bảo chúng khả thi và có

hiệu quả.

1.4. Giới thiệu về dự án xây dựng cổng thông tin điện tử Bộ GTVT

1.4.1. Giới thiệu dự án

Cổng thông tin điện tử Bộ Giao thông vận tải được xây dựng trên cơ sở nâng

cấp Trang thông tin điện tử của Bộ nhằm nâng cao hơn nữa chất lượng và hiệu quả

công tác truyền thông của Bộ Giao thông vận tải; liên kết, tích hợp các kênh thông

tin, các ứng dụng và các dịch vụ công trực tuyến của các cơ quan, đơn vị thuộc Bộ

Giao thông vận tải phục vụ công tác quản lý nhà nước và phục vụ người dân, doanh

nghiệp và đảm bảo cung cấp thông tin đầy đủ, kịp thời theo quy định tại Nghị định

số 43/2011/NĐ-CP ngày 13/6/2011 của Chính phủ quy định về việc cung cấp thông

tin và dịch vụ công trực tuyến trên trang thông tin điện tử hoặc cổng thông tin điện

tử của cơ quan nhà nước và theo yêu cầu của ngành Giao thông vận tải.

Nội dung và cấu trúc Cổng thông tin điện tử Bộ Giao thông vận tải được kế

thừa toàn bộ các tính năng, ứng dụng, dữ liệu của hệ thống Trang thông tin điện tử

và được bổ sung thêm các yêu cầu, ứng dụng mới đáp ứng nhu cầu hiện tại và có

khả năng phát triển mở rộng trong tương lai. Cổng thông tin điện tử Bộ Giao thông

vận tải bao gồm trên 20 chuyên trang, chuyên mục, tiện ích và tích hợp các trang

thông tin chuyên ngành, cơ sở dữ liệu chuyên ngành, các dịch vụ công trực tuyến…

Đặc biệt, lần đầu tiên xuất hiện các chuyên trang, chuyên mục mới trên Cổng như

Bộ Giao thông vận tải với công dân; Giao lưu, phỏng vấn trực tuyến; Thủ tục hành

chính...

1.4.2. Các mục tiêu và yêu cầu

Cổng thông tin điện tử Bộ Giao thông Vận tải được xây dựng cần đáp ứng

được đầy đủ các mục tiêu và yêu cầu cơ bản sau:

- Đảm bảo tạo ra một địa chỉ cung cấp những thông tin, dịch vụ công của Bộ

cho người dân và doanh nghiệp.

- Nâng cao chất lượng công tác thông tin, tuyên truyền về các lĩnh vực thuộc

phạm vi quản lý nhà nước của Bộ GTVT.

- Liên kết, tích hợp các kênh thông tin, các ứng dụng và các dịch vụ công trực

tuyến của các cơ quan đơn vị trực thuộc Bộ để cung cấp những thông tin, thực hiện

tốt hơn công việc quản lý nhà nước của Bộ.

- Là trung tâm cho phép tích hợp thông tin, dữ liệu từ trang thông tin điện tử

hoặc công thông tin của các đơn vị trực thuộc Bộ.

- Hỗ trợ các đơn vị, cán bộ công chức trong Bộ trực tiếp cung cấp thông tin

theo thẩm quyền và tham gia quản trị Cổng thông tin điện tử.

- Tạo ra môi trường tương tác 2 chiều giữa Bộ với các cá nhân, tổ chức.

- Làm nền tảng cho việc tiếp tục phát triển mở rộng về chiều rộng (Số lượng

các chuyên mục thông tin và dịch vụ công) và chiều sâu (mức độ tương tác 2 chiều

giũa Bộ và công dân, doanh nghiệp) góp phần vào công cuộc đơn giản hóa các thủ

tục hành chính tiến tới hoàn thiện mô hình Chính phủ điện tử của Bộ.

1.4.3. Các nội dung cụ thể

Việc xây dựng Cổng thông tin điện nhằm đáp ứng một số nội dung cụ thể như sau:

- Cổng thông tin điện tử ứng các nội dung quy định tại Điều 28 Luật công

nghệ thông tin, Điều 4 của Nghị định số 43/2011/ NĐ- CP ngày 13/6/2011 của

Chính phủ quy định về việc cung cấp thông tin và dịch vụ công trực tuyến trên trang

thông tin điện tử hoặc công thông tin điện tử của cơ quan nhà nước.

- Cung cấp các kênh trao đổi thông tin giữa Bộ với người dân và doanh

nghiệp. Hỗ trợ trao đổi thông tin, dịch vụ thông tin và lấy ý kiến về văn bản quy

phạm pháp luật.

- Tạo nền tảng vững chắc, để sẵn sàng mở rộng về số lượng kênh thông tin và

chất lượng thông tin của Bộ theo thời gian phù hợp với sự tăng trưởng theo từng năm.

- Giúp thống nhất, tập hợp các trang thông tin thành phần và nội dung thông

tin của các đơn vị trực thuộc Bộ thành một hệ thống thống nhất.

- Cung cấp cơ chế mở để dễ dàng liên kết, trao đổi thông tin với Cổng thông

tin của Chính phủ và các Cổng thông tin điện tử hoặc các Trang thông tin điện tử

của các đơn vị liên quan.

- Tập huấn cho các lãnh đạo và chuyên viên tham gia sử dụng tốt Cổng thông

tin điện tử. Đào tạo đội ngũ cán bộ chuyên trách để quản lý và cận hành Cổng thông

tin điện tử.

- Đảm bảo các yêu cầu, tiêu chuẩn công nghệ hiện hành về cổng thông tin điện tử.

1.5. Tiểu kết chương

Chương này tôi đã trình bày lý thuyết nền về rủi ro, các yếu tố rủi ro trong dự

án phần mềm, quy trình nhận diện quản lý rủi ro. Tôi cũng đã trình bày về dự án

xây dựng cổng thông tin điện tử Bộ GTVT.

Chương tiếp theo tôi sẽ đi sâu tìm hiểu về phương pháp quản trị rủi ro hướng

mục tiêu và thử nghiệm áp dụng trong quá trình xây dựng cổng thông tin điện tử Bộ

GTVT.

Chương II: PHƯƠNG PHÁP QUẢN TRỊ RỦI RO HƯỚNG MỤC TIÊU

2.1. Tổng quan về quản trị rủi ro hướng mục tiêu

2.1.1. Mô hình quan hệ của quản trị rủi ro hướng mục tiêu

Hình 2.1: Mô hình quan hệ của phương pháp quản trị rủi ro hướng mục

tiêu [4]

Mô hình được thể hiện trên Hình 2.1, thể hiện các mức độ trừu tượng từ mục

tiêu (Goals) đến trở ngại (Obstacle) và cuối cùng là điều trị và theo dõi (Treatment

and monitor).

* Mục tiêu (Goals): mục đích kỳ vọng và hạn chế của các thành phần phát

triển (development components).

* Trở ngại (Obstacle): là yếu tố rủi ro – các vấn đề trực tiếp hoặc gián tiếp cản

trở mục tiêu để hoàn thành và gây ra các vấn đề phát triển phần mềm

* Hậu quả (Consequence): các sự kiện không mong muốn do các trở ngại và

rủi ro ở trên gây ra và những sự kiện này tiếp tục mang lại hậu quả tiêu cực đến các

mục tiêu.

* Điều trị và theo dõi (Treatment and monitor): Các hành động kiểm soát, cản

trở rủi ro và hậu quả của chúng và góp phần đạt được các mục tiêu. Điều trị rủi ro

cũng đòi hỏi việc theo dõi hiệu quả của các hoạt động kiểm soát và để xác định bất

kỳ rủi ro mới trong quá trình phát triển.

Có ba chế độ xem mô hình khác nhau được cấu trúc bởi quản trị rủi ro hướng

mục tiêu liên quan đến mục tiêu, những trở ngại và mối quan hệ nhân quả:

Mô hình mục tiêu (Goal model): Mục tiêu là khái niệm cốt lõi của cách tiếp

cận này. Nó chỉ rõ những mong đợi, mục tiêu và khó khăn của các thành phần phát

triển (development components), các bên liên quan và môi trường kinh doanh liên

quan đến sự thành công của dự án. Các mục tiêu được phân tích từ các mức cao cho

đến các mức thấp hơn, để có thể định lượng được các mục tiêu. Do đó mô hình mục

tiêu cho thấy sự tương tác giữa các mục tiêu cấp cao hơn với các mục tiêu cấp thấp

hơn. Mô hình được biểu diễn bởi một sơ đồ, trong đó bao gồm các mục tiêu và liên

kết của chúng, từ các mục tiêu cao hơn đến cấp thấp hơn.

Mô hình trở ngại (Obstacle model): Trở ngại là sự phủ nhận các mục tiêu và

chịu trách nhiệm về sự xuất hiện của bất kỳ sự kiện không mong muốn nào trong

suốt dự án phát triển phần mềm và sử dụng sản phẩm. Những trở ngại và hậu quả

của chúng được xác định, phân tích và được ưu tiên bằng cách làm theo các mục

tiêu đã được xác định. Tương tự như mục tiêu, trở ngại cũng được xây dựng từ yếu

tố rủi ro (risk factor) cho sự kiện rủi ro (risk event). Do đó, mô hình trở ngại mô tả

mô hình mục tiêu (ví dụ goal-risk model) bằng cách bao gồm các liên kết từ các trở

ngại (obstacle) đến các mục tiêu (goals) và từ các yếu tố nguy cơ (risk factor) đến

sự kiện rủi ro (risk event).

Mô hình mối quan hệ nhân quả (Causal relationship model): Các yếu tố rủi ro

có thể gây ra một hoặc nhiều sự kiện rủi ro gây ảnh hưởng tiêu cực tới các mục tiêu.

Điều này cho phép chúng tôi mô phỏng mối quan hệ nhân quả giữa các sự kiện rủi

ro và các yếu tố liên quan cũng như sự cản trở của chúng tới mục tiêu. Mô hình mô

tả các yếu tố nguy cơ nào có liên quan với nhau và làm thế nào chúng chịu trách

nhiệm với sự kiện sự kiện rủi ro xảy ra.

2.1.2.Mô hình lớp của quản trị rủi ro hướng mục tiêu:

a) Lớp mục tiêu (Goals Layer)

Lớp mục tiêu tập trung vào các yếu tố góp phần hiệu quả vào việc hoàn thành

các hoạt động của dự án và trực tiếp liên kết với thành công của dự án. Những mục

tiêu này là quan trọng vì họ mô tả những gì cần phải làm để một dự án thành công

và định hướng để các nhân viên có trách nhiệm để đạt được các mục tiêu.

Mục tiêu trong GSRM xem xét một số trọng số của các thành phần phát triển

phần mềm bao gồm thực hiện dự án, quy trình, sản phẩm, con người và môi trường

bên trong và bên ngoài (như đã nêu trong phần 4 trước) và lập bản đồ cho các chỉ số

thành công của dự án. Hoạt động chính của lớp này là xác định và mô hình các mục

tiêu. Tuy nhiên, trước khi xác định mục tiêu cụ thể, các bên có liên quan cần đồng ý

về một kế hoạch quản lý rủi ro, đặc biệt là phạm vi quản lý rủi ro, ngưỡng rủi ro và

các nguồn lực. Mô hình hoá mục tiêu hỗ trợ tạo ra các mục tiêu cấp thấp mục tiêu

phụ thông qua AND hoặc OR. Mục tiêu càng được chi tiết thì càng dễ cho việc xác

định và phân tích các yếu tố nguy cơ cản trở mục tiêu. Một biểu diễn đồ thị

(graphical representation) của quá trình sàng lọc mục tiêu là phần cốt lõi của mô

hình mục tiêu. Sự thỏa mãn các mục tiêu phụ này chắc chắn đạt được sự thỏa mãn

mục tiêu chính. Một mục tiêu phụ có thể làm thỏa mãn nhiều hơn một thành phần

phát triển (development component). Những mục tiêu phụ này rất quan trọng cho

dự án và cần quan tâm hơn đến sự thành công của chúng. Vì vậy, nếu được yêu cầu,

các mục tiêu được ưu tiên theo tầm quan trọng đối với sự thành công của dự án.

b) Lớp trở ngại (Obstacle Layer)

Trở ngại là những nguyên nhân chính làm giảm khả năng đạt được một hoặc

nhiều mục tiêu. Chúng tôi coi các yếu tố nguy cơ (risk factors) là những trở ngại trực

tiếp hoặc gián tiếp dẫn đến một sự phủ định mục tiêu và tạo ra các vấn đề trong dự

án.Trở ngại là sự đối lập của các mục tiêu. Vì vậy, các trở ngại cần được liên kết và bắt

nguồn từ các mục tiêu và mô hình tình trạng về một số trở ngại vi phạm các mục tiêu

đã được xác định. Tương tự với mô hình mục tiêu, mô hình trở ngại cũng tinh chỉnh để

cung cấp một tổng quan về các yếu tố nguy cơ tồn tại trong dự án. Trọng tâm chính là

để xác định càng nhiều yếu tố nguy cơ càng tốt, để có thể lựa chọn các hành động kiểm

soát tương ứng trong giai đoạn đầu. Các yếu tố rủi ro trong phát triển phần mềm

(Software development risk factors) hỗ trợ các loại trở ngại khác nhau như như: Sự

không hài lòng, thiếu tính đầy đủ, thông tin sai lệch, không chính xác.

Lớp trở ngại hỗ trợ các hành động nhận dạng rủi ro và GSRM sử dụng một

danh sách các câu hỏi toàn diện và sắp xếp chúng dựa theo phân cấp thành phần để

xác định các yếu tố nguy cơ. Điều này hỗ trợ phân loại các yếu tố rủi ro và nhóm

chúng trong cùng một loại. Lưu ý rằng, cũng có các yếu tố nguy cơ mà có thể không

trực tiếp cản trở một mục tiêu cụ thể nhưng gây ra vấn đề trong quá trình phát triển.

Lớp này không những cho phép các loại rủi ro như vậy được thể hiện và được trình

bày như các yếu tố nguy cơ, cả trong cùng một dự án, mà còn là một yếu tố nguy cơ

có thể sử dụng lại (reusable risk factor component). Ví dụ về những trở ngại như

vậy là: sự tin tưởng giữa khách hàng và người hành nghề, …. Lớp cản trở thiết lập

mối liên kết cản trở từ các yếu tố nguy cơ đến các sub-goals (mục tiêu phụ) và từ sự

kiện đến mục tiêu chính. Cùng một trở ngại về rủi ro có thể liên quan đến nhiều hơn

một mục tiêu (goal). Điều này quan trọng cần được thể hiện bởi các lớp trở ngại rủi

ro (risk obstacle layer), vì nó là thông tin quan trọng khi xem xét các biện pháp điều

trị hiệu quả. Xác định yếu tố rủi ro, phân loại và mô hình hoá là nhiệm vụ chính của

lớp này. Tuy nhiên các rủi ro được xác định bởi lớp này không đủ để xác định các

hành động kiểm soát bởi vì các yếu tố nguy cơ cần phải được định lượng để xác

định mức độ nghiêm trọng của nó. Vì vậy, những trở ngại đã được xác định được

phân tích sâu hơn trong lớp đánh giá.

c) Lớp đánh giá

Các lớp đánh giá phân tích các sự kiện rủi ro như là một kết quả của một hoặc

nhiều yếu tố nguy cơ đến mục tiêu. Định lượng rủi ro là một bước quan trọng đầu

tiên trong việc đánh giá rủi ro. Tuy nhiên, nhiệm vụ này là không tầm thường do

bản chất chủ quan vốn có của các rủi ro trong lĩnh vực công nghệ phần mềm. Lớp

này chú thích từng rủi ro trong phát triển phần mềm. Hơn nữa, nó cũng thiết lập mô

hình mối quan hệ nhân quả giữa các yếu tố nguy cơ và các sự kiện rủi ro. Lớp tập

trung vào mức độ nghiêm trọng của rủi ro sự kiện dẫn tới sự phủ định mục tiêu. Vì

vậy, mối quan hệ giữa các rủi ro (tech-nical hay non-technical) trong phát triển phần

mềm và đánh giá dựa trên quan điểm tương ứng với các mục tiêu của dự án tiềm

năng là sự đóng góp chính của lớp này. Đối với mục tiêu phát triển phần mềm ưu

tiên cao, nhận dạng trở ngại và sàng lọc cần được rộng rãi. Chúng ta sử dụng Mạng

Belief Bayesian (Bayesian Belief Network) để hỗ trợ mô hình mối quan hệ nhân

quả bằng cách lập bản đồ các yếu tố mô hình nguy cơ (risk modeling elements)

thành các nút xác suất. Mỗi sự kiện rủi ro được đặc trưng bởi hai tính chất: khả

năng và tác động. Khả năng xác định khả năng xảy ra sự kiện rủi ro và được mô

hình như một tài sản của sự kiện rủi ro. Tác động định lượng kết quả tiêu cực gây ra

bởi rủi ro cho một hoặc nhiều mục tiêu. Cùng một yếu tố rủi ro (risk factor) có thể

dẫn đến nhiều hơn một sự kiện rủi ro (risk event) và cùng một sự kiện rủi ro có thể

cản trở nhiều mục tiêu. Mặt khác, một mục tiêu bị cản trở bởi nhiều trở ngại, các trở

ngại lại có liên hệ đến các sự kiện rủi ro và nhiều yếu tố kết hợp. Biểu diễn này cho

phép mô hình được tình huống một sự kiện (event) bị ảnh hưởng bởi nhiều yếu tố

rủi ro và tác động lên một hoặc nhiều những mục tiêu. Một liên kết cản trở

(obstruction link) được thiết lập từ sự kiện rủi ro (risk event) đến mục tiêu cụ thể mà

nó cản trở. Điều này hỗ trợ xây dựng mô hình nguy cơ - mục tiêu (goal-risk model)

bằng cách tinh chỉnh các yếu tố rủi ro (risk factors) tới các sự kiện rủi ro và sự cản

trở kết hợp của chúng tới các mục tiêu. Sự tinh chỉnh trở ngại (obstacle refinement)

được thực hiện theo cách ngược lại so với sự tinh chỉnh mục tiêu (goal refinement).

Lợi ích của tinh chỉnh trở ngại là chúng ta không cần phải phân tích từng nhân tố rủi

ro đơn nhất một cách riêng biệt và trong hoàn cảnh thực tế của dự án, điểm này rất

quan trọng, đặc biệt khi ngân sách và nguồn lực còn hạn chế.

c) Lớp ứng phó

Lớp cuối cùng tập trung vào các hành động kiểm soát để chống lại các rủi ro

nhằm đạt được mục tiêu một cách đúng đắn. Một khi các mục tiêu, các yếu tố rủi ro

(risk factor) và các sự kiện rủi ro được xác định và phân tích bởi lớp mục tiêu, lớp

trở ngại và lớp đánh giá, sau đó nhiệm vụ cuối cùng là thực hiện các biện pháp đối

phó có hiệu quả về chi phí. Do đó, mục đích của lớp này là để kiểm soát rủi ro phát

triển phần mềm càng sớm càng tốt trong giai đoạn yêu cầu kỹ thuật của sự quá trình

phát triển (requirements engineering phase of the development). Lớp cũng chịu

trách nhiệm giám sát tình trạng rủi ro trong suốt quá trình phát triển và nếu cần thiết

trong quá trình vận hành và duy trì sản phẩm. Tuy nhiên, các quan tâm ban đầu là

tập trung vào các sự kiện rủi ro và các yếu tố liên quan gây ảnh hưởng tiêu cực tới

một số mục tiêu, ví dụ như các rủi ro được ưu tiên cao. Nói chung, tồn tại một lựa

chọn các phương pháp đối phó cho những trở ngại nhưng nên lựa chọn một cách

hiệu quả nhất để giảm nhẹ rủi ro. Lớp này bao gồm hai liên kết khác nhau: liên kết

đóng góp (contribution link) đi từ hành động kiểm soát (control action) đến mục

tiêu mà nó đáp ứng và liên kết cản trở (obstruction link) đi từ hành động kiểm soát

đển những trở ngại (obstacle) cụ thể mà nó cản trở. Lớp điều trị (Treatment layer)

cho phép mô hình hóa, lập luận và theo dõi hành động kiểm soát cho giảm thiểu rủi

ro và thỏa mãn các mục tiêu. Nó cũng bao gồm liên kết trách nhiệm (responsibility

link) từ hành động kiểm soát đến đại lý (agent) để các đại lý hoạt động (active

agent) cụ thể có trách nhiệm thực hiện hành động kiểm soát để giảm nhẹ rủi ro. Các

hành động kiểm soát rủi ro cần giảm thiểu, ngăn ngừa hoặc tránh rủi ro phần mềm

để đạt được những mục tiêu. Tuy nhiên, bối cảnh dự án là rất quan trọng để xác

định và chọn hành động kiểm soát thích hợp. Nếu một dự án có nguy cơ cao từ lúc

bắt đầu, hành động kiểm soát được lựa chọn ban đầu nên tập trung để loại bỏ hoàn

toàn rủi ro. Tuy nhiên, không phải lúc nào cũng có thể loại bỏ các yếu tố rủi ro. Các

đại lý hệ thống (system agents) chẳng hạn như con người và các thành phần phát

triển khác như công cụ hoặc quy trình nên chịu trách nhiệm thực hiện một nhiệm vụ

cụ thể cho hành động kiểm soát được lựa chọn. Việc xử lý rủi ro xem xét đến

ngưỡng rủi ro (risk threshold) - mức cụ thể mà dự án có thể chấp nhận rủi ro mà

không thực hiện bất kỳ hành động kiểm soát nào.. Một khi hành động kiểm soát rủi

ro được chọn được thực hiện thì chúng ta cần giám sát tình trạng rủi ro (risk status)

cho đến khi nó hoàn toàn giảm nhẹ. Tình trạng rủi ro thông qua quá trình phát triển

sẽ tiến triển. Cụ thể, hành động kiểm soát có thể không làm giảm tác dụng của các

rủi ro hoặc các rủi ro mới được xác định. Do đó, lớp xử lý tiếp tục giám sát rủi ro

trong suốt quá trình phát triển và thông tin với các bên liên quan về tình hình rủi ro

bằng cách báo cáo tình trạng rủi ro.

Hình 2.2 mô tả khung mô hình của GSRM (modeling framework of GSRM).

GSRM sử dụng cùng một kí hiệu mục tiêu (hình bình hành) và chướng ngại vật

(hình bình hành ngược). Trên đầu trang là lớp mục tiêu (goals layer) tinh chỉnh mục

tiêu thông qua AND và OR, từ đó sàng lọc thành các mục tiêu phụ (sub-goals). Hai

lớp ở giữa đại diện cho các rủi ro phát triển phần mềm như là các trở ngại gây cản

trở trực tiếp đến các mục tiêu và vấn đề phát triển. Và dưới cùng là lớp điều trị

(treatment layer) ban đầu có chứa các mục tiêu về phòng ngừa, giảm thiểu và tránh

rủi ro và phân công trách nhiệm cho các đại lý (agent) thực hiện các hành động

kiểm soát được lựa chọn để cản trở các trở ngại. Lớp điều trị bao gồm các liên kết

đóng góp (contribution link), liên kết cản trở (obstruction link) và liên kết trách

nhiệm (responsibility link) tới ba lớp đầu. Framework này bắt đầu với mục tiêu

trong các điều kiện thành công của dự án và kết thúc bằng các mục tiêu về giảm

thiểu rủi ro.

Hình 2.2: Mô hình lớp của phương pháp quản trị rủi ro hướng mục tiêu [4]

2.2. Mô hình quy trình và hoạt động thực hiện của phương pháp

Các hoạt động quản lý rủi ro dựa trên mục tiêu (goal-driven risk management)

được thực hiện tuần tự và lặp lại. Hình 2.3. cho biết tổng quan về các hoạt động,

nhiệm vụ và các bước liên quan đến mô hình quy trình. Hoạt động ban đầu là có

trách nhiệm khởi tạo các hoạt động quản lý rủi ro dựa trên mục tiêu trong suốt quá

trình yêu cầu - kỹ thuật. Một khi các bên liên quan của dự án đồng ý về kế hoạch

quản lý rủi ro thì theo tuần tự các hoạt động còn lại sẽ được thực hiện.

Hình 2.3: Mô hình của phương pháp quản trị rủi ro hướng mục tiêu [4]

2.2.1. Hoạt động 1: Khởi tạo

Trọng tâm chính của hoạt động này là để phê duyệt việc quản lý rủi ro như là

một phần của dự án phát triển phần mềm của chính các bên liên quan dự án. Vì vậy,

hoạt động này yêu cầu sự tham gia tích cực của các ban quản lý (management),

quản lý của dự án (project manager) để nhấn mạnh tầm quan trọng của việc quản lý

rủi ro từ giai đoạn sớm của phát triển.

a) Xác định rủi ro của dự án

Nhiệm vụ này thường được thực hiện trong giai đoạn lập kế hoạch dự án. Tuy

nhiên, nếu nhiệm vụ đã không được thực hiện trước đó, thì sau đó GSRM sẽ chủ

trương xem xét nó trước khi xác định phạm vi quản lý rủi ro (risk management

scope).

Mỗi dự án đều có một mục đích chung là không mất bất kỳ khoản tiền nào.

Ngoài ra còn có các dự án mà các tổ chức thực hiện để có được kinh nghiệm/kiến

thức hoặc danh tiếng cao cho sự tăng trưởng kinh doanh trong tương lai. Tuy nhiên,

bất kể lợi ích gì vào cuối, hầu hết các dự án đều tập trung vào việc hoàn vốn đầu tư.

Do đó, tính khả thi về mặt kinh tế, về các chi phí và lợi ích tiềm tàng cả về số lượng

cũng như chất lượng và tính khả thi về mặt kỹ thuật và hoạt động nói chung được

phân tích rộng rãi trong giai đoạn lập kế hoạch dự án (project planning phase).

b) Quản lí rủi ro theo kế hoạch

Nhiệm vụ bắt đầu thực hiện trong giai đoạn phát triển ban đầu của GSRM. Nó

tập trung vào một số thông số được yêu cầu xác nhận từ người quản lý dự án và các

bên liên quan chính của dự án bao gồm: Phạm vi quản lý rủi ro (management

scope), các sự kiện rủi ro chung (generic risk events), các ngưỡng giới hạn

(associated thresholds), schedule và nguồn lực (schedule and resource), chiến lược

điều trị rủi ro và theo dõi. Các hiện vật dự án (project artifacts) chính như mục tiêu

kinh doanh, tài liệu ủy quyền dự án (ví dụ như tầm nhìn hệ thống, kế hoạch dự án,

ngân sách và lịch trình, thông tin liên quan) và tính chất rủi ro của dự án được yêu

cầu để xác định các tham số khởi tạo rủi ro. Chúng tôi giả định, vào giai đoạn đầu,

khi dự án được khởi xướng thì các mục tiêu kinh doanh và phạm vi dự án đã được

xác định và tầm nhìn hệ thống đã sẵn sàng cho khách hàng phê chuẩn.

2.2.2. Hoạt động 2: Xác định mục tiêu

Khi kế hoạch quản lý rủi ro được khởi tạo, thì hoạt động tiếp theo là xác định

và từ đó mô hình hóa các mục tiêu bằng cách tập trung vào trạng thái của các thành

phần phát triển và lập bản đồ cho các yếu tố thành công của dự án. Hoạt động này

xác định các mục tiêu, kỳ vọng và các ràng buộc của hệ thống yếu tố thành phần, để

những người tham gia dự án đóng góp để hoàn thành những ràng buộc này trên con

đường dẫn đến con đường phát triển thành công. Hoạt động bao gồm hai nhiệm vụ

khác nhau: xác định, phân loại các mục tiêu và mô hình các mục tiêu. Các mục tiêu

đã được xác định, nếu cần, tinh chế hoặc sửa đổi sao cho phản ánh được mong đợi

của các bên liên quan, các yếu tố thành công của dự án, phạm vi dự án và mục đích

kinh doanh. Các mục tiêu càng được xây dựng chi tiết càng tốt vì nó giúp dễ dàng

nhận biết trở ngại cho bất kỳ bối cảnh nào (context).

a) Xác định và phân loại mục tiêu

Các mục tiêu chủ yếu là những kỳ vọng, những ràng buộc và những vấn đề từ

dự án bản văn. Nhiệm vụ này xác định và phân loại các mục tiêu của các thành phần

phát triển. Chúng tôi đưa ra một bộ quy tắc giúp hỗ trợ công việc này và bênh vực

cho sử dụng nó trong suốt thời gian rủi ro - quản lý.

b) Xây dựng mô hình mục tiêu

Các mục tiêu đã xác định yêu cầu cần phải được liên kết với nhau, để xác định

vai trò của chúng trong việc hoàn thành các hoạt động phát triển phần mềm

(software development activities). Thỉnh thoảng một số mục tiêu được xác định là

quá trừu tượng khiến khó hiểu được ý nghĩa cụ thể của mục tiêu. Do đó, các mục

tiêu ban đầu có thể cần được tinh chế (refine) để cung cấp ý nghĩa cụ thể hơn, về

đóng góp của chúng cho thành công của dự án. Ví dụ, quản lý dự toán ngân sách

phát triển là một mục tiêu quan trọng. Nhưng các bên liên quan có thể cảm thấy

rằng mục tiêu đó là trừu tượng và cần những chi tiết đầy đủ. Mục tiêu đòi hỏi phải

sàng lọc các mục tiêu phụ như các mốc thời gian rõ ràng, ước lượng chính xác và

các mục tiêu phụ (sub-goals) khác có liên quan để chúng có thể đóng góp chung để

đạt được mục tiêu chính (main goals). Nhiệm vụ này tập trung vào việc sàng lọc

mục tiêu và thiết lập liên kết sàng lọc từ mục tiêu phụ thành mục tiêu của cha mẹ.

Sàng lọc (refinement) sẽ được biểu diễn ngược lại bằng cách xác định mục tiêu trừu

tượng qua các câu hỏi WHY, để đạt được các mục tiêu cha mẹ từ sự đóng góp của

các mục tiêu phụ [09]. Mặt khác, sàng lọc có thể được xây dựng bằng cách đặt câu

hỏi HOW. Cụ thể, làm thế nào các mục tiêu cha mẹ có thể đạt được thông qua các

mục tiêu phụ. Trong mô hình điểm mục tiêu, tùy thuộc vào ngữ cảnh, có thể áp

dụng tính năng AND và OR. Sàng lọc AND: có nghĩa là mục tiêu cấp cao hơn chỉ

có thể được đáp ứng bằng cách đáp ứng tất cả các mục tiêu phụ thấp hơn. Sàng lọc

OR: có nghĩa là mục tiêu cao hơn có thể được đáp ứng bằng cách đáp ứng bất kỳ

mục tiêu phụ nào. Các mục tiêu càng chi tiết hơn, thì việc xác định những trở ngại

và phương pháp điều trị dễ dàng hơn. Mô hình hỗ trợ liên kết đóng góp

(contribution link) đi từ mục tiêu phụ tới mục tiêu cha mẹ.

2.2.3. Hoạt động 3: Xác định trở ngại

Hoạt động này xác định danh sách các yếu tố nguy cơ gây trở ngại cho các

mục tiêu đã được xác định và mô hình chúng như bằng các liên kết cản trở mục tiêu

(goal obstruction links). Tương tự với định nghĩa mục tiêu, chúng ta dựa theo hệ

thống phân cấp yếu tố thành phần phát triển để xác định và phân loại các yếu tố

nguy cơ. Hoạt động này có hai nhiệm vụ khác nhau và chi tiết của từng nhiệm vụ

được đưa ra ở dưới.

a) Xác định và phân loại các yếu tố rủi ro

Những trở ngại chính từ môi trường phát triển lúc đầu cản trở mục tiêu và gây

ra các vấn đề trong và sau khi phát triển được xác định và phân loại bởi bước này.

Chúng ta cần xác định càng nhiều trở ngại càng tốt để nhóm phát triển

(development team) ý thức được những vấn đề từ giai đoạn đầu. Có hai đặc tính

mong muốn chính là một trở ngại cần phải tuân thủ: tính đầy đủ (completeness) và

nhất quán (consistency). Tính đầy đủ (completeness) xác định liệu những trở ngại

đã được xác định có đủ để cản trở một mục tiêu cụ thể. Tài sản này cho phép xem

xét tất cả các cách có thể mà các mục tiêu có thể bị cản trở. Tính nhất quán

(consistency) xác định liệu có bất kỳ xung đột nào tồn tại giữa các trở ngại đã được

xác định hay không. Một trở ngại tương tự không nên được thể hiện bằng tên khác.

Do đó, tính đầy đủ và tính nhất quán của trở ngại thường phụ thuộc vào miền kiến

thức đầy đủ (adequate domain knowledge) về nguy cơ phần mềm và bối cảnh của

dự án. Để hỗ trợ hai thuộc tính này, chúng ta cần phân loại tất cả các trở ngại đã

được xác định bằng cách dựa theo hệ thống phân cấp component-element-factor. Có

một số loại trở ngại cản trở mục tiêu cho dự án phát triển phần mềm. Và loại cản trở

(obstacle category) phải chịu ảnh hưởng bởi loại mục tiêu (goal category). Ví dụ.

nếu sự hài lòng (satisfaction ) hỗ trợ mục tiêu thì sự không hài lòng (dissatisfaction)

sẽ cân nhắc các vấn đề phản đối mục tiêu hài lòng. Các rủi ro được xác định có thể

là lớn và có thể đại diện cho các yếu tố nguy cơ (risk factors) tương tự từ các quan

điểm khác nhau. Cần phân loại các yếu tố nguy cơ. Chúng ta làm theo phân loại của

chúng ta về yếu tố thành phần phát triển mà có liên quan đến các mục tiêu.

b) Xây dựng mô hình Mục tiêu- rủi ro (Goals-risk)

Mô hình rủi ro mục tiêu là một phần mở rộng của mô hình mục tiêu bằng cách

bao gồm liên kết cản trở từ những trở ngại cho các mục tiêu. Tương tự như sàng lọc

mục tiêu, những trở ngại cũng được tinh chế thông qua việc AND hoặc OR tinh

chỉnh. Tinh chỉnh AND cho thể hiện một hay nhiều trở ngại phụ (sub-obstacles)

cùng thỏa mãn trở ngại của cha mẹ và tinh chỉnh OR cho thấy các cách khác nhau

từ các trở ngại phụ để đáp ứng trở ngại cha mẹ. Mô hình mục tiêu – rủi ro (goal-

risk) bao gồm mô hình trở ngại để tinh chỉnh các yếu tố nguy cơ cho các sự kiện rủi

ro. Mô hình trở ngại đòi hỏi phải xác định các sự kiện rủi ro từ yếu tố rủi ro để các

yếu tố nguy cơ được tinh chỉnh thành các sự kiện rủi ro và các sự kiện đã xác định

cũng tạo ra cản trở liên quan đến các mục tiêu cụ thể. Mô hình mục tiêu - rủi ro bao

gồm việc tinh chỉnh các mục tiêu thành các mục tiêu phụ (sub-goals) và tinh chỉnh

các yếu tố nguy cơ thành các sự kiện có nguy cơ. Nó bao gồm hai liên kết khác

nhau: một là liên kết đóng góp từ mục tiêu phụ đến các mục tiêu và từ các yếu tố

nguy cơ đối với các sự kiện rủi ro và liên kết cản trở từ các yếu tố nguy cơ và các sự

kiện rủi ro đến các mục tiêu. Điều này cho phép xác định biểu hiện trực quan của

các mục tiêu và các yếu tố nguy cơ. Mô hình cũng cho thấy các mục tiêu phụ quan

trọng và các yếu tố nguy cơ cần được chú ý hơn so với các mục tiêu khác. Và thông

tin này là rất quan trọng ở bất kỳ giai đoạn nào của sự phát triển. Các yếu tố nguy

cơ phát triển phần mềm nói chung được tinh chế bởi OR bởi vì rất khó để yêu cầu

hoặc đo lường rằng tất cả các yếu tố nguy cơ sẽ cùng chịu trách nhiệm cho sự xuất

hiện của một sự kiện rủi ro (tức là điều kiện của AND là phức tạp hơn). Tuy nhiên,

trọng tâm cần đảm bảo tính nhất quán và đầy đủ liên quan đến việc sàng lọc từ yếu

tố nguy cơ sang sự kiện rủi ro để không nên bỏ qua bất kỳ yếu tố nguy cơ quan

trọng nào. Trước khi xây dựng mô hình mục tiêu-rủi ro, nhiệm vụ này xác định các

sự kiện rủi ro bị ảnh hưởng bởi các yếu tố rủi ro đã được xác định từ hoạt động

trước đó. Để làm cho công việc trở nên đơn giản, xem xét ban đầu sẽ là các sự kiện

rủi ro thông thường đối với mọi dự án như: ngân sách thiếu hụt, các yêu cầu bị sai

và sau đó là các sự kiện rủi ro cụ thể của dự án. Một khi tất cả các sự kiện rủi ro

được xác định, thì mô hình mục tiêu - rủi ro có thể được xây dựng.

2.2.4. Hoạt động 4: Đánh giá rủi ro

Hoạt động này định lượng một rủi ro đơn bằng cách ước lượng mức độ rủi ro

và ưu tiên.

a) Định lượng rủi ro

Mỗi rủi ro được ước lượng thông qua hai tính chất: khả năng và mức độ

nghiêm trọng của tác động mà rủi ro gây ra. Tuy nhiên định lượng rủi ro luôn là

thách thức trong các dự án phát triển phần mềm [4]. Trong đánh giá rủi ro phát triển

phần mềm, sự không chắc chắn (uncertainties) liên quan đến nhiều yếu tố và được

bao quanh bởi hệ thống phân cấp yếu tố thành phần. Chúng tôi dựa theo các mục

tiêu và các loại của mục tiêu để gợi ra một sự kiện rủi ro tùy thuộc điều kiện phụ

thuộc vào các yếu tố nguy cơ. Một yếu tố nguy cơ có thể ảnh hưởng đến một hoặc

nhiều sự kiện rủi ro tùy theo bối cảnh. Ví dụ, kiến thức về lĩnh vực hành nghề

không đầy đủ, sự can thiệp thụ động của khách hàng / người sử dụng, các điều

khoản không rõ ràng trong yêu cầu là các yếu tố nguy cơ ảnh hưởng đến sự xuất

hiện của một số sự kiện rủi ro liên quan như yêu cầu sai lầm, vượt quá lịch trình

(schedule-overruns) và chất lượng sản phẩm kém. Do đó, mối quan hệ nhân quả

giữa các yếu tố nguy cơ và các sự kiện giúp ta xác định nền tảng có điều kiện của

các yếu tố nguy cơ quan trọng ở giai đoạn phát triển ban đầu. Để ước lượng rủi ro,

chúng ta đo khả năng xảy ra sự kiện rủi ro và ảnh hưởng của biến cố đó đến các

mục tiêu. Do đó, kết quả của nhiệm vụ này ưu tiên rủi ro để có thể xác định và sử

dụng các biện pháp điều trị đầy đủ càng sớm càng tốt.

b) Ưu tiên rủi ro

Ưu tiên rủi ro xác định những rủi ro nào cần được chú ý ngay lập tức. Đôi khi

không thể nhìn vào tất cả các rủi ro đã được xác định do ngân sách, thời gian biểu

hoặc những ràng buộc khác. Do đó nhiệm vụ cuối cùng của hoạt động đánh giá rủi

ro này ưu tiên rủi ro quan trọng nhất trong bối cảnh dự án. Ưu tiên rủi ro cũng xem

xét mức độ tương tự như trong dự báo nguy cơ và ước tính tác động của rủi ro, tức

là bao gồm rất quan trọng, quan trọng và ít quan trọng .Chúng ta sử dụng ma trận ưu

tiên rủi ro bằng cách xem xét các giá trị xác suất sự kiện và các giá trị tác động.

Phát triển phần mềm theo hướng truyền thống, độ ưu tiên rủi ro dựa trên khả năng

và các giá trị tác động, bằng cách kết hợp các mức cao nhất thu hút nhiều sự chú ý

nhất đến xếp loại rủi ro và lựa chọn hành động kiểm soát. Sự ưu tiên sau đó tập

trung vào sự kết hợp vừa và trung bình trong khi ngững rủi ro có độ ưu tiên thấp có

thể bị bỏ qua. Tuy nhiên, có hai sự kết hợp khác: cao thấp và thấp - cao. Rủi ro có

khả năng xảy ra thấp nhưng có ảnh hưởng lớn thường được gọi là các sự kiện cực

đoan. Các sự kiện cực đoan rất khó xử lý, đặc biệt ở giai đoạn đầu của quá trình

phát triển. Một sự kiện rủi ro có khả năng xảy ra cao và tác động thấp cũng đòi hỏi

sự chú ý để các hành động điều trị đóng góp cho việc giảm giá trị có thể xảy ra. Các

rủi ro được ưu tiên cao, tức là 10 rủi ro hàng đầu hoặc 20 rủi ro thu hút người quản

lý dự án để lựa chọn các hoạt động kiểm soát ngay lập tức.

2.2.5. Hoạt động 5: Quản lý và giám sát rủi ro

Đây là hành động cuối cùng của GSRM. Hành động này kiểm soát rủi ro càng sớm

càng tốt và giám sát hiệu quả của các hành động kiểm soát. Nó cũng xác định bất kỳ rủi

ro mới nào ở giai đoạn sau của dự án. Hoạt động này xác định các biện pháp đối phó có

khả năng xảy ra và lựa chọn các biện pháp thích hợp nhất để giảm thiểu rủi ro. Đây là

một hoạt động liên tục trong quá trình phát triển và bao gồm ba nhiệm vụ.

a) Xử lý rủi ro theo kế hoạch

Nhiệm vụ chủ yếu là xác định các hành động kiểm soát liên quan đến việc

kiểm soát các sự kiện rủi ro và lựa chọn các hành động thích hợp nhất để có thể

thực hiện ngay. Nó bao gồm hai bước chính: Xác định các hành động kiểm soát rủi

ro có thể và chọn những hành động tiềm năng nhất. Các bước trong nhiệm vụ này

được liên kết với nhau. Việc lựa chọn các hoạt động kiểm soát phù hợp chủ yếu phụ

thuộc vào các biện pháp đối phó được xác định và chiến lược kiểm soát tổng thể rủi

ro. Do đó, bước đầu tiên cần phải thực hiện đầy đủ và chính xác để có thể lựa chọn

hành động kiểm soát phù hợp

• Tránh rủi ro: Tránh rủi ro xem xét các lựa chọn thay thế khác, để kiểm soát

rủi ro và các yếu tố liên quan, để tránh các hậu quả tiêu cực của sự kiện rủi ro với

các mục tiêu có thể tránh được.

• Không có hành động kiểm soát: Tùy chọn này được ưa thích trong một số

tình huống như nếu thông tin đầy đủ không có sẵn ở giai đoạn đầu, thông tin đắt đỏ

hoặc rủi ro có mức ưu tiên trung bình hoặc thấp.

• Phòng ngừa rủi ro: Chiến lược này ngăn ngừa rủi ro bằng cách loại bỏ khả

năng xảy ra sự kiện rủi ro hoặc loại bỏ các hậu quả có ảnh hưởng đến mục tiêu. Tuy

nhiên, thực tế không đảm bảo rằng các biện pháp đối phó cụ thể có khả năng loại bỏ

hoàn toàn nguy cơ và hậu quả liên quan của nó.

• Giảm rủi ro: Như đã nêu, việc loại bỏ hoàn toàn chướng ngại vật không phải

lúc nào cũng có thể do đó giảm rủi ro là một lựa chọn thay thế để giảm thiểu rủi ro

đến mức mong muốn. Giảm rủi ro tập trung vào làm giảm khả năng xảy ra sự kiện

rủi ro hoặc ảnh hưởng của sự xuất hiện đến các mục tiêu.

• Rủi ro giữ lại: Nếu bất kỳ chiến lược nào ở trên không phù hợp với rủi ro thì

rủi ro có thể giữ lại như là sự lựa chọn cuối cùng. Nó được sử dụng khi không có

khả năng kiểm soát các yếu tố rủi ro. Tuy nhiên, tình trạng này là rất hiếm ởgiai

đoạn phát triển sớm. Kết quả nghiên cứu của chúng tôi cho thấy rằng các nhà quản

lý dự án chủ yếu quan tâm đến việc tránh rủi ro ở giai đoạn này bằng cách lựa chọn

các hành động kiểm soát thích hợp.

Các chiến lược này sẽ hướng dẫn lựa chọn được biện pháp đối phó có thể xảy

ra. Tuy nhiên, các chiến lược này không phải là một danh sách tối ưu định nghĩa các

biện pháp đối phó. Nó luôn đòi hỏi sự thảo luận chặt chẽ giữa các thành viên tham

gia dự án để lựa chọn những biện pháp thích hợp.

Hình 2.4: Chiến lược kiểm soát rủi ro

b) Phân công trách nhiệm xử lý

Xử lý rủi ro do các thành phần chủ động thực hiện roles cụ thể cho sự hài lòng

mục tiêu trong việc phát triển phần mềm. Các hành động xử lý rủi ro tạo ra một

hoặc nhiều nhiệm vụ và các đại lý có trách nhiệm thực hiện các nhiệm vụ ấy, từ đó

thực hiện các hành động kiểm soát. Nhiệm vụ này xác định các tác nhân, phân bổ

nguồn lực, nếu cần, gán trách nhiệm thực hiện cho các hành động kiểm soát.

c) Giám sát rủi ro trong suốt quá trình phát triển

Các rủi ro nói chung phát triển theo thời gian, trong quá trình phát triển, sử

dụng và duy trì sản phẩm. Hơn nữa, những rủi ro mới cũng có thể xuất hiện. Việc

giám sát chúng liên tục là điều rất cần thiết và hiệu quả để phân tích sự thay đổi rủi

ro trong dự án phần mềm. Hoạt động này được bắt đầu khi những rủi ro xác định

được phân tích và các hoạt động kiểm soát được thực hiện. Đây là một nhiệm vụ

theo dõi liên tục tình trạng của các rủi ro đã được xác định và các hành động kiểm

soát trong một khoảng thời gian đều đặn. Khoảng thời gian thường xuyên cho giám

sát rủi ro không phải lúc nào cũng có thể có kế hoạch chặt chẽ và còn phải chịu áp

lực ngân sách. Giám sát rủi ro cũng phụ thuộc vào mức độ rủi ro dự án nói chung.

2.2.6. Đặc tả rủi ro (Risk Specification)

Đặc tả rủi ro phản ánh nhu cầu thiết yếu để quản lý rủi ro từ giai đoạn đầu

thông qua triển khai để duy trì phần mềm. Các hoạt động của GSRM trong phần

trước, sau đó mô tả các khái niệm cơ bản, sự phụ thuộc giữa các khái niệm và cú

pháp tương ứng của đặc tả rủi ro. Các loại rủi ro có chứa các nội dung như: mục

tiêu, trở ngại và điều trị (treatment) và các khái niệm như: chi tiết mục tiêu, chi tiết

rủi ro, báo cáo trạng thái rủi ro, mô hình mục tiêu-rủi ro (goal-risk), mô hình mối

quan hệ nhân quả và sự phụ thuộc của khái niệm này. Bất kỳ khái niệm nào trong

đặc tả rủi ro đều dựa trên các thuộc tính hoặc tính chất để xác định nội dung của các

hiện vật. Nội dung và khái niệm cho phép phân biệt cấu trúc của hiện vật và các

khái niệm cơ bản.

2.3. Vai trò và trách nhiệm (Roles & Responsibilities)

GSRM giới thiệu các hoạt động quản lý rủi ro có hệ thống rõ ràng trong giai

đoạn yêu cầu kỹ thuật [4]. Cách tiếp cận đòi hỏi một định nghĩa rõ ràng về vai trò

và trách nhiệm cho việc biểu diễn các hoạt động theo mô hình quy trình. Tồn tại các

vai trò bổ sung trực tiếp hỗ trợ các hoạt động quản lý rủi ro giống như người quản

lý dự án. Nói chung, trong dự án phần mềm, vai trò được phân biệt và phân công

cho các thành viên trong nhóm, cho dù kích thước dự án là gì. Nhưng trong các dự

án nhỏ, một số roles có thể được thực hiện bởi một người.

2.3.1. Người quản lý rủi ro:

Người quản lý rủi ro đóng vai trò quan trọng cho toàn bộ quá trình của quá

trình quản lý rủi ro phát triển phần mềm hướng mục tiêu. Nói chung, người quản lý

rủi ro có trách nhiệm chính trong việc tạo ra và duy trì các hiện vật mô tả rủi ro và

truyền tải thông tin rủi ro với ban quản lý, người thực hiện và người sử dụng. Vai

trò này cần có trách nhiệm đặc biệt để tạo ra thông tin chính xác và kịp thời về rủi

ro trong quá trình phát triển sớm.Người quản lý rủi ro cần thông báo thêm thông tin

về rủi ro này cho các thành viên chính của dự án. Các trách nhiệm cho người quản

lý rủi ro bao gồm:

• Lập kế hoạch và thực hiện quản lý rủi ro trong giai đoạn đầu của dự án và

tiếp tục giám sát rủi ro trong suốt vòng đời của sản phẩm.

• Trao đổi thông tin về rủi ro với người tham gia dự án và các bên liên quan.

• Thực hiện các hoạt động quản lý rủi ro và phối kết hợp với những người

tham gia khác.

• Quản lý hiện vật mô tả rủi ro.

• Đảm bảo hiệu quả của quá trình quản lý rủi ro và thu thập phản hồi để cải

tiến toàn bộ quá trình.

• Lập kế hoạch và đào tạo nhóm phát triển về quản lý rủi ro phát triển phần

mềm.

2.3.2. Chủ dự án:

Chủ dự án, còn được gọi là nhà tài trợ dự án, kiểm soát các nguồn lực và giám

sát tiến trình chung và sự thành công của dự án. Chủ dự án hành động thay mặt cho

đại diện của bộ phận quản lý và yêu cầu sự hiểu biết về tầm quan trọng của việc

quản lý rủi ro trong phát triển phần mềm trong suốt dự án. Sự hỗ trợ từ người quản

lý là rất quan trọng trong việc quản lý rủi ro hiệu quả. Cụ thể, chủ dự án có trách

nhiệm đưa ra những đề nghị liên quan đến các hoạt động quản lý rủi ro trong quá

trình phát triển.

2.3.3. Người quản lý dự án:

Người quản lý dự án chịu trách nhiệm cho việc thực hiện dự án tổng thể và

thực hiện quản lý rủi ro xảy ra trong dự án. Việc phân bổ thời gian hợp lý cho các

hoạt động quản lý rủi ro, khi nào và bởi ai sẽ được thống nhất giữa ban quản lý,

người quản lý dự án và các thành viên dự án. Người quản lý dự án phân bổ hỗ trợ

đào tạo việc quản lý rủi ro cho những người tham gia dự án. Trong tình huống thực

tế với một dự án quy mô vừa và nhỏ, đôi khi vai trò của người quản lý rủi ro không

thể được phân bổ cho một người chuyên dụng, do những hạn chế về nguồn lực.

Trong trường hợp đó, người quản lý dự án thực hiện vai trò này ngoài vai trò chính

của mình. Do đó, người quản lý dự án phải có kiến thức và kinh nghiệm đầy đủ để

đánh giá và quản lý rủi ro phần mềm trong quá trình phát triển. Mặc dù nếu người

quản lý rủi ro tồn tại trong dự án, người quản lý dự án cũng cần tham gia tích cực

vào các hoạt động quản lý rủi ro.

2.3.4. Người tham gia dự án:

Người tham gia dự án như kỹ sư yêu cầu, kiến trúc sư, nhà thiết kế, lập trình

viên, QA/tester và người quản lý phát hành cần phải có ý tưởng cơ bản về khái niệm

quản lý rủi ro phần mềm, để họ có nhận thức chung về rủi ro và truyền đạt nguy cơ

tiềm ẩn cho các thành viên khác trong đội. Điều này tạo nên sự hiệu quả cho việc

quản lý rủi ro trong quá trình phát triển. Những người tham gia cũng cần phải làm

quen với các hoạt động, nhiệm vụ và hiện vật liên quan đến quản lý rủi ro phát triển

phần mềm. Vì GSRM tập trung vào việc tích hợp trong yêu cầu, Kỹ sư yêu cầu nên

tham gia tích cực vào các hoạt động mô hình hóa mục tiêu và rủi ro. Thông thường,

kỹ sư yêu cầu chịu trách nhiệm về việc tạo và duy trì các hiện vật mô tả đặc điểm

yêu cầu. Việc tích hợp quản lý rủi ro vào RE cho phép xác định sự phụ thuộc giữa

yêu cầu và các hiện vật mô tả rủi ro. Do đó nó có hiệu quả, nếu kỹ sư tích cực tham

gia vào các hoạt động quản lý rủi ro. Điều này cho phép một mặt duy trì tính nhất

quán giữa các hiện vật và mặt khác làm giảm sự tích hợp của GSRM trong kỹ thuật

yêu cầu.

2.3.5. Người sử dụng:

Tương tự như nhà phát triển phần mềm, vận hành và bảo trì, người dùng cũng

hỗ trợ rất hiệu quả trong quản lý rủi ro. Rủi ro trong môi trường người dùng hoặc

các quan điểm người dùng chỉ có thể được giải quyết bởi người dùng, chẳng hạn

như các rủi ro liên quan đến yêu cầu, triển khai sản phẩm, sử dụng và bảo trì.

Những rủi ro này không nằm trong sự kiểm soát của người quản lý dự án. Việc

thông báo cho người dùng về tình trạng cập nhật rủi ro được cập nhật và liên quan

đến việc giải quyết rủi ro luôn luôn rất quan trọng.

2.3. Ý tưởng áp dụng quản trị rủi ro hướng mục tiêu trong các dự án phần mềm

Để đảm bảo đạt được hiệu quả kinh tế cao trong quá trình thực hiện dự án,

trong quá trình thực hiện (Nhất là các dự án thực hiện dài ngày thì có khả năng xảy

ra rủi ro và gây ra các thiệt hại nặng lề về của cải vật chất, con người) chính vì vậy

để hạn chế các thiệt hại do các sự kiện rủi ro gây lên, vì vậy mới tiến hành xây dựng

dự án phần mềm. Quản trị rủi ro dựa trên phần mềm này để áp dụng cho việc quản

lý rủi ro hướng mục tiêu trong các dự án đầu tư xây dựng công trình giao thông vận

tải, dân dụng, công nghiệp trong Bộ GTVT sẽ đạt được hiệu quả kinh tế cao so với

mức chi phí đầu tư xây dựng, quản trị phần mềm. Thực hiện tốt nội dung quản trị

dự án phần mềm sẽ góp phần đảm bảo thực hiện các mục tiêu đã đề ra.

Phần mềm cho phép sau khi đăng nhập thì có thể quản lí các dự án của mình,

quản lí trực tiếp thông tin từng dự án (thông tin chi tiết dự án, quản lí mục tiêu, quản lí

loại rủi ro, quản lí các tác nhân rủi ro của dự án, quản lí các phương pháp giải quyết

từng rủi ro, quản lí và theo dõi tình trạng của các rủi ro, quản lí các xung đột trong dự

án, và quản lí trọng số hàm thích nghi ) và yêu cầu trợ giúp ra quyết định.

2.4. Kết luận chương 2

Qua quá trình nghiên cứu các nội dung ở trêntôi hiểu rằng đây là một phương

pháp có tính thực tế cao, đã đưa ra được các cơ sở nhận biết rủi ro hướng mục tiêu,

mô hình quản trị rủi ro,các phương pháp quản trị rủi ro hướng mục tiêu rất khoa học

mang tính thực tiễn, tính khả thi và có hiệu quả kinh tế cao, hoàn toàn có thể sử

dụng trong quản lý dự án, góp phần giúp nhà đầu tư thực hiện được hoàn thành các

mục tiêu đã đề ra.

Chương III. ỨNG DỤNG THỬ NGHIỆM PHƯƠNG PHÁP QUẢN

TRỊ RỦI RO HƯỚNG MỤC TIÊU TRONG DỰ ÁN XÂY DỰNG CỔNG

THÔNG TIN ĐIỆN TỬ BỘ GTVT

3.1.Xây dựng giải pháp ứng dụng

3.1.1. Mô hình hóa chức năng

Sử dụng biểu đồ ca sử dụng để mô tả các chức năng của phần mềm. Người

dùng tham gia vào hệ thống. Sau khi đăng nhập thì có thể quản lí các dự án của

mình, quản lí trực tiếp thông tin từng dự án (thông tin chi tiết dự án, quản lí mục

tiêu, quản lí loại rủi ro, quản lí các tác nhân rủi ro của dự án, quản lí các phương

pháp giải quyết từng rủi ro, quản lí và theo dõi tình trạng của các rủi ro,quản lí các

xung đột trong dự án, và quản lí trọng số hàm thích nghi) và yêu cầu trợ giúp ra

quyết định.

Hình 3.1 Biểu đồ usecase sử dụng của hệ thống

3.1.2.Thiết kế các thực thể

Biểu đồ dưới đây mô tả các thực thể trong một dự án:

Hình 3.2 Biểu đồ UML các thực thể trong một dự án

3.1.3. Thiết kế cơ sở dữ liệu

Cơ sở dữ liệu được thiết kế như sau:

Hình 3.3 Cơ sở dữ liệu – quan hệ giữa các bảng

Bảng users: Lưu thông tin người dùng phần mềm để thực hiện việc quản trị rủi ro

của dự án. Chiết các trường của bảng này được mô tả trong Bảng 3.1.

Bảng 3.1 : Mô tả bảng người sử dụng Users

Tên Kiểu dữ liệu Mô tả

mediumint(8) Khóa chính id UNSIGNED

varchar(16) Địa chỉ ip ip_address

Tên truy cập của người varchar(100) username dùng

varchar(50) Tên của người dùng name

varchar(80) Mật khẩu truy cập password

Chuỗi random được thêm

varchar(40) vào để hash cùng với salt

password

Email người dùng varchar(100) email

Avatar người dùng varchar(255) avatar

activation_code varchar(40) activation_code

forgotten_password_code forgotten_password_code varchar(40)

int(11) UNSIGNED forgotten_password_time forgotten_password_time

varchar(40) remember_code remember_code

int(11) UNSIGNED Thời điểm tạo created_on

int(11) UNSIGNED Lần cuối đăng nhập last_login

tinyint(1) Trạng thái active active UNSIGNED

int(11) Xóa deleted

Bảng Projects: Lưu thông tin về dự án trong quá trình thực hiện việc quản trị rủi ro của dự án. Chiết các trường của bảng này được mô tả trong Bảng 3.2.

Bảng 3.2 : Mô tả bảng Projects

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID người dùng user_id

varchar(20) Mã dự án code

varchar(50) Tên dự án name

Mô tả text description

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng Goal_Categories: Lưu trữ thông tin các phân loại mục tiêu, giúp người quản

trị dự án xây dựng các phân loại của mục tiêu, để qaunr lý tốt hơn các mục tiêu. Chi

tiết thông tin các trường của bảng này được mô tả trong Bảng 3.3.

Bảng 3.3 : Mô tả bảng Goal_Categories

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

varchar(20) Mã loại mục tiêu code

varchar(50) Tên loại mục tiêu name

text Mô tả description

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng Goals: Lưu trữ thông tin các mục tiêu giúp người quản trị xây dựng các mục

tiêu quản trị rủi ro một cách hiệu quả nhất. Chi tiết các trường của bảng này được

liệt kê trong Bảng 3.4.

Bảng 3.4: Mô tả bảng Goals

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

int(11) ID loại mục tiêu goal_type_id

varchar(20) Mã mục tiêu code

varchar(50) Tên mục tiêu name

text Mô tả description

int(11) Mã của mục tiêu chính parent_goal_id

varchar(50) Mức độ quan trọng của mục tiêu goal level

(Extreme, High, Medium, Low)

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng Risk_Factors : Lưu trữ thông tin các yếu tố rủi ro. Các trường của bảng

được xây dựng như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được

liệt kê trong Bảng 3.5.

Bảng 3.5 : Mô tả bảng Risk_factors

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

varchar(20) Mã yếu tố rủi ro code

varchar(50) Tên yếu tố rủi ro name

text Mô tả description

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng Risk_types : Lưu trữ thông tin các phân loại rủi ro. Các trường của bảng được

xây dựng như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được liệt

kê trong Bảng 3.6.

Bảng 3.6 : Mô tả bảng Risk_types

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

varchar(20) Mã loại rủi ro code

varchar(50) Tên loại rủi ro name

text Mô tả description

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng Risks : Lưu trữ thông tin của rủi ro. Lưu trữ thông tin các yếu tố rủi ro. Các

trường của bảng được xây dựng như trong mô tả ở Chương 2. Chi tiết các trường

của bảng này được liệt kê trong Bảng 3.7.

Bảng 3.7: Mô tả bảng Risks

Kiểu dữ liệu int(11) int(11) int(11) varchar(20) Mô tả Khóa chính ID dự án ID loại rủi ro Mã rủi ro Tên id project_id risk_type_id code

Tên rủi ro Mô tả

varchar(50) text int(11) name description financial impact

varchar(50) risk level

Thiệt hại khi xảy ra rủi ro, thường là số tiền ($) Mức độ xảy ra của rủi ro (Extreme, High, Medium, Low)

timestamp int(11) Thời điểm tạo Xóa createdAt deleted

Bảng Riskfactor-Riskevent: Lưu trữ quan hệ giữa yếu tố rủi ro-sự kiện rủi ro.

Các trường của bảng được xây dựng như trong mô tả ở Chương 2. Chi tiết các

trường của bảng này được liệt kê trong Bảng 3.8.

Bảng 3.8: Mô tả bảng Riskfactor-Riskevent

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

int(11) Mã quan hệ code

varchar(20) ID rủi ro risk_id

varchar(50) ID yếu tố rủi ro risk_factor_id

text Mô tả description

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng risk-goal: Lưu trữ quan hệ giữa rủi ro- mục tiêu. Các trường của bảng được

xây dựng như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được liệt

kê trong Bảng 3.7.

Bảng 3.9: Mô tả bảng riskfactor-goal

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

int(11) Mã quan hệ code

varchar(20) ID rủi ro risk_id

varchar(50) ID mục tiêu goal_id

text Mô tả description

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng Agents : Lưu trữ thông tin các Agents. Các trường của bảng được xây dựng

như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được liệt kê trong

Bảng 3.10.

Bảng 3.10 : Mô tả bảng Agents

Kiểu dữ liệu int(11) varchar(20) varchar(50) text Mô tả Khóa chính Mã agent Tên agent Mô tả Tên id code name description

timestamp int(11) Thời điểm tạo Xóa

createdAt deleted

Bảng Methods : Lưu trữ thông tin phương án xử lí rủi ro. Các trường của bảng

được xây dựng như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được

liệt kê trong Bảng 3.11.

Bảng 3.11 : Mô tả bảng Methods

Kiểu dữ liệu Mô tả int(11) int(11) varchar(20) varchar(50) int(11) Tên id risk_id code name cost

int(5) int(5) int(11) int(11) diff priority time responsible_agent_id

Khóa chính ID rủi ro Mã phương pháp Tên phương pháp Chi phí tiền khi giải quyết bằng phương pháp đó Độ khó Độ ưu tiên Thời gian giải quyết ID agent chịu trách nhiệm thực hiện Tình trạng tiến hành Trạng thái của rủi ro Mô tả Thời điểm tạo Xóa varchar(20) varchar(20) text timestamp int(11)

action_status risk_status description createdAt deleted

Bảng Conflicts : Lưu trữ thông tin xung đột. Các trường của bảng được xây dựng

như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được liệt kê trong

Bảng 3.12.

Bảng 3.12 : Mô tả bảng Conflicts

Kiểu dữ liệu Mô tả Tên

int(11) Khóa chính id

int(11) ID dự án project_id

int(11) ID phương pháp method_1_id

int(11) ID phương pháp method_2_id

varchar(20) Mã xung đột code

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

Bảng fitness : Lưu trữ thông tin trọng số hàm Fitness. Các trường của bảng được

xây dựng như trong mô tả ở Chương 2. Chi tiết các trường của bảng này được liệt

kê trong Bảng 3.13.

Bảng 3.13 : Mô tả bảng fitness

Tên Kiểu dữ liệu Mô tả

int(11) Khóa chính id

int(11) ID dự án project_id

int(11) Trọng số rủi ro risk

int(11) Trọng số phương pháp method

int(11) Trọng số thiệt hại khi xảy ra rủi ro financial_impact

int(11) Trọng số mức độ xảy ra rủi ro risk_level

int(11) Trọng số chi phí tiền cost

int(11) Trọng số độ khó diff

int(11) Trọng số độ ưu tiên priority

int(11) Trọng số thời gian time

timestamp Thời điểm tạo createdAt

int(11) Xóa deleted

3.1.4. Xây dựng các chức năng phần mềm

• Chức năng quản lý

Cho phép hiển thị, thêm mới, sửa, xóa, tìm kiếm, sắp xếp, lọc các thông tin

cần quản lí: dự án (project), agent, mục tiêu (goal), yếu tố rủi ro (risk factor), rủi ro

(risk), quan hệ yếu tố rủi ro – rủi ro, quan hệ rủi ro – mục tiêu, giải pháp của rủi ro,

Agent: Code: mã agent; Name: tên agent.; Description: mô tả agent; Type:

xung đột giữa các giải pháp. Cụ thể, nội dung của từng thành phần:

loại của agent (ví dụ ‘person’);

Project: Code: mã dự án, Name: tên dự án. Description: mô tả dự án; Goal:

Code: mã mục tiêu, Name: tên mục tiêu, Description: mô tả mục tiêu, Level: mực

Risk Factor: Code: mã yếu tố rủi ro; Name: tên yếu tố rủi ro; Description: mô

quan trọng của mục tiêu.

Risk: Code: mã rủi ro; Name: tên rủi ro; Description: mô tả rủi ro; financial

tả yếu tố rủi ro;

Risk Factor – Risk: Code: mã quan hệ yếu tố rủi ro- rủi ro; Description: mô

impact: Thiệt hại khi xảy ra rủi ro ($); Level: mực độ nghiêm trọng của rủi ro;

Risk – Goal: Code: mã quan hệ rủi ro – mục tiêu; Description: mô tả.

Method: Code: mã phương pháp; Name: tên phương pháp; Description: mô tả

tả.

phương pháp; Cost: Chi phí khi thực hiện phương pháp; Diff : Độ khó của phương

pháp (thang từ 0-9); Priority: Độ ưu tiên; Time: Thời gian giải quyết.

• Chức năng yêu cầu đưa ra quyết định

Đưa ra gợi ý với mỗi rủi ro thì nên sử dụng phương pháp điều trị nào với mục

đích để hạn chế xung đột giữa các phương pháp điều trị.

Công cụ phát triển phần mềm: phần mềm phát triển sử dụng ngôn ngữ lập

trình PHP với Framework Codeigniter. Công cụ quản trị cơ sở dữ liệu: MySql.

Phần đã được hoàn thiện và có giao diện chính như ở Hình 3.4 và Hình 3.5.

Giao diện Đăng nhập vào hệ thống:

Hình 3.4: Giao diện trang đăng nhập

Giao diện chính làm việc của trang quản lý rủi ro:

Hình 3.5: Giao diện trang quản lý rủi ro dự án

3.2. Sử dụng phần mềm áp dụng trong quản trị rủi ro xây dựng phần mềm

cổng thông tin Bộ GTVT

Sử dụng dữ liệu từ dự án thực tế của Bộ giao thông vận tải [1], đưa vào quản lí

bởi ứng dụng được trình bày như dưới đây:

Các dữ liệu để đăng nhập vào hệ thống dưới đây được lấy từ Ban quản lý dự

án cho một số chức năng cụ thể trong quá trình thực hiện Dự án:

Xác định và quản lí các mục tiêu của dự án:

Mục tiêu chính khi thực hiện dự án được xây dựng và chi tiết hóa thành các

mục tiêu cấp 2 như mô tả trong Bảng 3.14.

Mã

Tên

Mô tả

Mức độ đánh

STT

giá

Công tác chuẩn bị và phê I duyệt Dự án

Xây dựng nhiệm vụ quy hoạch của

DA, phê duyệt, xây dựng hồ sơ thiết

kế cơ sở của hệ thống (phần cứng, Chuẩn bị tốt công tác rà

High G001

soát và xây dựng phê duyệt dự án

phần mềm, phương án triển khai hệ thống mạng), phê duyệt thiết kế cơ sở, thực hiện tốt công tác thiết kế kỹ thuật, thiết kế kỹ thuật thực hiện các mô đun phần cứng, phần mềm, xây dựng triển khai hệ thống mạng

High II Thực hiện đầu tư xây dựng

thi công hệ 1 G002 Thực hiện thống mạng ở Bộ GTVT

Thực hiện khoan tường, chuẩn bị các điểm lắp đặt Switch, đào đường, lắp đặt ống dây để kéo dây hệ thống mạng

2 G003 Kéo dây, lắp đặt Switch, các ổ mạng cho các phòng làm việc Thực hiện thi công lắp đặt hệ thống Switch và kéo dây mạng

3 G004 Hoàn thiện hệ thống mạng Hoàn thiện kiểm tra các ổ mạng (tới từng phòng), Switch đảm bảo kết nối

4 G005 Gồm 5 mô đun chính XD hệ thống phần mềm bao gồm các mô đun chính như trong thiết kế phần

mềm

Thực hiện ghép nối các Kiểm tra hệ thống phần mềm hoạt 5 G006 chức năng mô đun phần động thông suốt mềm

Thực hiện kiểm thử các Kiểm thử các chức năng phần mềm, 6 G007 chức năng hệ thống triển hệ thống mạng tại các đơn vị khai trên các đơn vị cục vụ

Thực hiện đào tạo cho các Lên danh sách đào tạo theo các chức 7 G008 phòng ban năng

Kiểm tra đánh giá toàn bộ Vận hành thử nghiệm hệ thống tại 8 G009 hệ thống các đơn vị để đánh giá

II Kết thúc đầu tư xây dựng High

Thực hiện việc đối chiếu giữa các

1 G010 Thẩm tra phê duyệt quyết toán dự án

tài liệu biên bản với công việc thực hiện thực tế và đưa ra kết luận cuối cùng.

2 G011 Kiểm toán dự án

Bộ phận kiểm toán dự án, thu thập tài liệu, số liệu đối chứng với các tiêu chuẩn quy định của nhà nước và đưa ra kết luận cuối cùng.

Đối thu thập tài liệu số liệu, thực

3 G012

Kiểm tra chứng nhận sự phù hợp các chức năng của hệ thống nghiệm thực tế tại dự án và đối chiếu với các tiêu chuẩn hiện hành để đưa ra kết luật cuối cùng

4 G013 Nghiệm thu bàn giao dự án đưa vào sử dụng

Các bộ phận chức năng của các đơn vị thực hiện nghiệm thu bàn giao để đưa dự án vào sử dụng theo luật định

5 G014 Bảo hành, bảo trì

Xây dựng các phương án bảo hành, bảo trì và tiến hành theo phương án đã xây dựng.

Bảng 3.14 : Xây dựng và quản lý các mục tiêu của Dự án

Quản lý mục tiêu:

Để quản lý tốt công tác chuẩn bị đầu tư:

+ Bộ phận quản lý phải chuẩn bị đầy đủ tài liệu của đơn vị thực hiện và các tài

liệu liên quan đến dự án như luật đầu tư, quy trình thực hiện một dự án theo luật

định và các văn bản khác có liên quan đến công tác phê duyệt dự án CNTT.

+ Thực hiện tốt việc xây dựng báo cáo tiền khả thi dự án theo luật định và

trình Văn phòng Bộ xem xét, phê duyệt đảm bảo rằng dự án nhận được chấp thuận

chủ trương đầu tư của lãnh đạo Bộ (Bộ trưởng).

+ Sau khi dự án đã nhận được văn bản chấp thuận chủ trương đầu tư của cơ

quan có thẩm quyền thì thực hiện đềnghị cấp Quyết định phê duyệt dự án.

+ Thẩm định và phê duyệt phương án chi tiết về nhân lực thực hiện dự án.

+ Chuẩn bị hồ sơ tài liệu gồm: (Quyết định phê duyệt dự án, Hồ sơ thiết kế dự

án, Danh mục thiết bị phần cứng, Chi tiết phương án thi công hệ thống mạng, Hồ sơ

thiết kế phần mềm, Kế hoạch triển khai, Kế hoạch đào tạo, Kế hoạch vận hành).

+ Sau khi nhận được Quyết định phê duyệt dự ánvà phê duyệt kế hoạch thực

hiện dự án thì tổ chức thực hiện các hồ sơ thiết kế và các công việc liên quan đến

việc thực hiện dự án theo luật định.

Quản lý các mục tiêu trong quá trình thực hiện thi công xây dựng dự án

+ Xem xét các giải pháp triển khai gồm:

•Xem xét mua sắm phần cứng.

•Xem xét triển khai hệ thống mạng.

•Xem xét triển khai xây dựng hệ thống phần mềm

•Biện pháp giám sát quản lý chất lượng thực hiện dự án (danh mục thiết bị,

chất lượng thi công hệ thống mạng, chất lượng triển khai phần mềm).

•Tiến độ thực hiện triển khai dự án:

+ Quản lý trong quá trình thực hiện:

Bám sát giải pháp xây dựng và đối chiếu với việc thực hiện thực tế của dự án

để có kết luận việc thực hiện dự án có đúng với kế hoạch đề ra, từ đó có biện pháp

khắc phục nếu thực hiện không đúng.

Quản lý các mục tiêu kết thúc đầu tư xây dựng nghiệm thu đưa dự án vào sử

dụng.

+ Quản lý xem xét hồ sơ từ khâu chuẩn bị đầu, thực hiện thi công

+ Đối chiếu lại với các quy định hiện hành (quy định về pháp lý, giá, …) của

Nhà nước để đưa ra các kết luận.

Xác định và quản lý các yếu tố nguy cơ:

Các nguy cơ có thể xảy ra trong quá trình thực hiện dự án.

STT Mã

Tên

Mô tả

Mức độ đánh giá

- Chậm tiến độ chuẩn bị thực hiện dự án: + Chưa nghiên cứu kỹ quy trình thực hiện đầu tư dự án + Chưa nắm vững ý tưởng của Lãnh đạo Bộ trong xây dựng dự án Công thông tin. + Do thay đổi cơ chế chính sách trong lĩnh vực CNTT-TT (các thông tư của Bộ TTTT) + Công tác khảo sát hệ thống mạng và các chức năng của các mô-đun phần mềm tại các đơn vị trong Bộ không đúng với kế hoạch tiến độ đã đề ra -Chậm tiến độ triển khai thực hiện dự án:

1 T01

Medium

+ Do điều kiện triển khai thực hiện dự án không đủ về số lượng và lạc hậu về công nghệ +Lực lượng tham gia thực hiện dự án

thiếu, trình độ chuyên môn kém;

+ Trình độ quản trị của các kỹ sư quản lý yếu kém, + Tiến độ cung cấp thiết bị không kịp thời...

Không đảm bảo đúng tiến độ: -Chuẩn bị thực hiện dự án: - Thi công thực hiện dự án

- Kết thúc dự án

-Chậm tiến độ kết thúc đầu tư xây dựng dự án. + Các văn bản không hợp lệ theo đúng quy trình + không đầy đủ các tài liệu +Có sự sai lệch giữa thực tế và thiết kế ban đầu...

2 T02

Thiên tai

Extreme

Do động đất, mưa bão, kéo dài thời gian thực hiện

3 T03

Vốn đầu tư

Medium

Kinh phí cấp qua văn phòng Bộ chưa kịp tiến độ

4 T04

Medium

Chất lượng dự án

5 T05

Medium

Sử dụng các trang thiết bị không đúng chủng loại theo đúng tiêu chí kỹ thuật đã được phê duyệt, kỹ thuật lắp đặt sai; giám sát thực hiện dự án không chặt chẽ về trang thiết bị, các chức năng phần mềm Không đạt dự kiến ban đầu: Do khảo sát nhu cầu của các đơn vị không kỹ,không lắm bắt được yêu cầu của các đơn vị, của lãnh đạo Bộ.

6 T06

Medium

Do tư duy ứng dụng CNTT ở các đơn vị sử dụng còn thấp.

7 T07

Low

Các chức năng thống của hệ phần mềm Tính trệ trì trong phối hợp ở các đơn vị Cháy nổ hoặc mất mát dữ liệu phần mềm

8 T08

Tai nạn

Medium

Do bất cẩn về cách thực hiện An ninh, an toàn cháy nổ trong quá trình thi công hệ thống mạng, điện và xây dựng phần mềm Do không chấp hành đúng nội quy an toàn Lao động

Bảng 3.15. Xác định và quản lý các yếu tố nguy cơ

Quản lý các nguy cơ khi thực hiện dự án: để đảm bảo không xảy ra các

nguy cơ trên thì việc tổ chức quản lý thực hiện dự án cần phải nghiên cứu sâu, thận

trọng trong từng công việc kể từ khi chuẩn bị cho đến khi kết thúc dự án như sau:

+ Để quản lý đề phòng nguy cơ chậm tiến độ chuẩn bị thực hiện dự án: Thì

tiến hành chuẩn bị dự án phải nghiên cứu thật kỹ quy trình thực hiện đầu tư dự án,

phải sử dụng cán bộ chuyên môn nắm vững các quy định của Nhà nước trong lĩnh

vực đầu tư. Hoặc có biện pháp kịp thời và thích ứng với việc thay đổi cơ chế chính

sách trong lĩnh vực đầu tư dự án.

+ Để quản lý nguy cơ chậm tiến độ thi công xây dựng dự án: Để không xảy ra

nguy cơ chậm tiến độ vì điều kiện thi công, phương tiện tham gia thực hiện dự án

không đủ về số lượng, lạc hậu về công nghệ thì: Cần lựa chọn nhà thầu có năng lực,

có kinh nghiệm. Đồng thời phải có kế hoạch, bảng biểu tiến độ thi công cụ thể.

Trường hợp để không xảy ra nguy cơ do lực lượng tham gia thực hiện dự án

thiếu, trình độ chuyên môn kém thì: Yêu cầu thi công lập tiến độ (bao gồm: Cung

ứng thiết bị, lực lượng tham gia thi công, khối lượng công việc hoàn thành) chi tiết

cho từng công việc theo ngày, tuần, tháng cụ thể để làm cơ sở giám sát nhà thầu.

Nếu xét thấy khi lực lượng không đủ thì phải thông báo trước cho nhà thầu để nhà

thầu tăng cường nhân lực tham gia dự án.

Quản lí rủi ro dự án: Các rủi ro có thể xảy ra trong quá trình thực hiện dự án

STT Mã

Tên

Mô tả

Mức độ đánh giá

- Chậm tiến độ chuẩn bị thực hiện dự án:

Không đảm bảo

+ Chưa nghiên cứu kỹ quy trình thực hiện đầu

đúng tiến độ:

tư dự án

+ Chưa nắm vững ý tưởng của Lãnh đạo Bộ

-Chuẩn bị thực

trong xây dựng dự án Công thông tin.

hiện dự án:

+ Do thay đổi cơ chế chính sách trong lĩnh

Medium

vực CNTT-TT (các thông tư của Bộ TTTT)

+ Công tác khảo sát hệ thống mạng và các

chức năng của các mô-đun phần mềm tại các

đơn vị trong Bộ không đúng với kế hoạch tiến

độ đã đề ra

1 T01

-Chậm tiến độ triển khai thực hiện dự án:

- Thi công thực

+ Do điều kiện triển khai thực hiện dự án

hiện dự án

không đủ về số lượng và lạc hậu về công nghệ

+Lực lượng tham gia thực hiện dự án

thiếu, trình độ chuyên môn kém;

High

+ Trình độ quản trị của các kỹ sư quản lý

yếu kém,

+ Tiến độ cung cấp thiết bị không kịp

thời...

- Kết thúc dự án

-Chậm tiến độ kết thúc đầu tư xây dựng dự

án.

+ Các văn bản không hợp lệ theo đúng quy

trình

+ không đầy đủ các tài liệu

+Có sự sai lệch giữa thực tế và thiết kế ban

đầu...

Do động đất, mưa bão, kéo dài thời gian thực

Thiên tai

2 T02 Extreme

hiện

Kinh phí cấp qua văn phòng Bộ chưa kịp tiến

Vốn đầu tư

3 T03 Medium

độ

Sử dụng các trang thiết bị không đúng chủng

loại theo đúng tiêu chí kỹ thuật đã được phê

Chất lượng dự

duyệt, kỹ thuật lắp đặt sai; giám sát thực hiện

4 T04 Low

án

dự án không chặt chẽ về trang thiết bị, các

chức năng phần mềm

Các chức năng

Không đạt dự kiến ban đầu: Do khảo sát nhu

của hệ thống

cầu của các đơn vị không kỹ,không lắm bắt

5 T05

phần mềm

được yêu cầu của các đơn vị, của lãnh đạo Bộ.

Tính trì trệ

Do tư duy ứng dụng CNTT ở các đơn vị sử

trong phối hợp

6 T06 Extreme

dụng còn thấp.

ở các đơn vị

Cháy nổ hoặc

Do bất cẩn về cách thực hiện An ninh, an toàn

mất mát dữ liệu

cháy nổ trong quá trình thi công hệ thống

7 T07 Medium

phần mềm

mạng, điện và xây dựng phần mềm

Do không chấp hành đúng nội quy an toàn

Tai nạn

8 T08 Low

Lao động

Bảng 3.16. Xây dụng các rủi ro có thể xảy ra trong quá trình thực hiện Dự án

Quản lí quan hệ nhân quả giữa yếu tố rủi ro- sự kiện rủi ro:

Trong quá trình thực hiện dự án nguy cơ rủi ro và rủi ro có quan hệ ảnh hưởng

trực tiếp theo tỷ lệ nghịch, Khi dự kiến được các nguy cơ xảy ra rủi ro và đề ra được

các biện pháp quản lý nguy cơ rủi ro tốt thì khả năng xuất hiện rủi ro thấp và ngược

lại nếu biện pháp quản lý nguy cơ kém thì khả năng xuất hiện rủi ro cao.

Quản lí quan hệ nhân quả giữa rủi ro - mục tiêu

Trong quá trình thực hiện dự ánrủi ro và mục tiêu có ảnh hưởng trực tiếp theo

tỷ lệ nghịch. Khi hạn chế các rủi ro xảy thì sớm hoàn thành mục tiêu đã đề ra.

Quản lí phương pháp điều trị và theo dõi rủi ro

STT Mã

Tên

Mô tả

Agent_code

Mã rủi ro

A01

1 PT1

M01

Chuyển rủi ro

2 PT2

A02

M02

Giảm thiểu rủi ro

3 PT3

A03

M03

Giảm thiểu rủi ro

PT4

Nâng cao A04

4 M04

A05

5 PT5

M05

A06

6 PT6

M06

A07

7 PT7

M07

Giảm thiểu rủi ro Giảm thiểu rủi ro Giảm thiểu rủi ro

A08

8 PT8

M08

Giảm thiểu rủi ro

Yêu cầu nhà thầu bổ sung thiết bị và thay thế các thiết bị lạc hậu, tăng nhân lực, tăng ca, trình độ chuyên môn thay thế cán bộ quản lý yếu kém, đảm bảo cung ứng vật tư, vật liệu tốt, hoặc thay thế nhà thầu khác có năng lực tốt hơn. Tự tổ chức các lực lượng thường trực trong các ngày mưa bão, huy động lực lượng làm tăng ca bù vào cho các ngày mưa bão... Tạm dừng chi phí cho các dự án chưa cần thiết khác, lên kế hoạch để huy động nguồn vốn trong các đơn vị, hoặc ngân hàng. Thay thế các cán bộ giám sát hoặc thay đổi hẳn đơn vị tư vấn giám sát có năng lực hơn..... Tăng cường công tác khảo sát và làm việc với các người dùng ở các phòng ban để xác định đúng các chức năng phần mềm Tổ chức học tập quán triệt tinh thần ứng dụng CNTT tại các đơn vị. Lãnh đạo Bộ quán triệt lãnh đạo các cục / vụ Đề nghị các nhà thầu phải học tập các nội quy an toàn PCCC và học tập các lớp huấn luyện của công an PCCC hướng dẫn Học tập phổ biến nội quy an toàn, an ninh lao động trong quá trình thực hiện dự án. Thực hiện các giải pháp sao lưu dữ liệu định kỳ

Bảng 3.17. Xây dụng phương pháp xử lý rủi ro và theo dõi rủi ro

Quản lý xung đột giữa các phương pháp điều trị

Trong quá trình đưa ra các giải pháp điều trị rủi ro thì mỗi một sự kiện rủi ro

đều ro mặc dù khi rủi ro xuất hiện thì đều gây ra thiệt hại về vật chất nhưng nguyên

nhân dẫn đến rủi ro là khác nhau vì vậy khi các giải pháp phương pháp điều trị rủi

ro có nội dung khác nhau. Do vậy để giải quyết xung đột giữa các giải pháp điều trị

(Phương án) khắc phục rủi ro cần thực hiện như sau:

- Xây dựng giải pháp điều trị rủi ro cho từng trường hợp cụ thể, trong mỗi giải

pháp điều trị rủi ro phải thể hiện rõ sự kiện rủi ro cụ thể, dự đoán mức độ thiệt hại

do sự cố rủi ro gây ra, tổ chức giải quyết rủi ro, người phụ trách bộ phận giải quyết

rủi ro, biện pháp cụ thể thực hiện giải quyết rủi ro.

VD: + Trường hợp rủi ro do thiên tai thì giải pháp xây phải thể hiện được mức

độ thiệt hại, biện pháp khắc phục bằng cách: Cần huy động tối đa lực lượng thiết bị

để di chuyển thiết bị, vật liệu đến nơi an toàn; sau sự cố bão lụt thì phải huy động

nhân lực, tăng ca để thực hiện các công việc bù lại thời gian ngừng thi công dự án.

+ Trường hợp thi công xây dựng dự án chậm tiến độ tùy từng nguyên nhân

gây ra chậm tiến độ thì có các biện pháp khắc phục sau:

Chậm do phương tiện tham gia thi công kém lạc hậu không đủ về số lượng,

lạc hậu về công nghệ thì cần phải lên kế hoạch và thông báo cho đơn vị thi công bổ

sung thêm thiết bị đồng thời thay thế các thiết bị lạc hậu.

Chậm do lực lượng tham gia thi công thiếu, trình độ chuyên môn kém thì: Yêu

cầu bổ sung lực lượng và thay thế các nhân lực yếu kém...

Chậm do tiến độ cung cấp vật tư vật liệu không kịp thời thì: Yêu cầu bằng các

biện pháp khác nhau phải cung cấp đầy đủ và kịp thời

Lập hồ sơ theo dõi rủi ro

Cử người phụ trách giải quyết sự cố rủi ro.

Yêu cầu trợ giúp ra quyết định

Khi nghiên cứu và đưa ra được (dự kiến các nguy cơ xảy ra rủi ro, rủi ro) thì

khi nhập dữ liệu thì trong phần mền quản lý rủi ro này sẽ đưa ra các giải pháp tố ưu,

từ đó bộ phận giải quyết rủi ro sẽ nhanh chóng nhận được và tiến hành triển khai

đảm bảo sớm khắc phục sự cố hạn chế thấp nhất thiệt hại do sự cố rủi ro gay ra góp

phần đảm bảo hoàn thành các mục tiêu của dự án đề ra.

3.3. Đánh giá và nhận xét về phần mềm và áp dụng trong Dự án xây dựng

cổng thông tin điện tử Bộ GTVT

• Về chức năng: Các chức năng cơ bản như thêm mới, sửa, xóa thông tin các

bản dữ liệu của phần mềm đã được hoàn thiện. Các phần ngoại lệ như: nhập thông

tin sai, nhập chữ vào phần số, để trống thông tin,.. cũng đã được chú ý và xử lý.

• Đặc biệt chức năng yêu cầu trợ giúp ra quyết định, giải thuật sử dụng chưa

được tối ưu, và chỉ chạy được với một số nhỏ trường hợp cố định, dẫn đến tốc độ

thực thi còn rất chậm cần phải được tối ưu hóa hơn.

• Về bảo mật: Đã xử lý được phần quản lí dự án theo user nhằm đảm bảo

thông tin dự án của user nào thì chỉ user đó và admin hệ thống biết. Tuy nhiên chưa

thực hiện bảo mật cho hệ thống, có nhiều lỗ hổng bào mật, lộ tên tham số trên link

dễ bị tấn công sql injection.

Phần mềm đã trợ giúp Ban quản lý dự án thực hiện quản trị rủi ro trong quá

trình thực hiện dự án.

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

1. Kết luận

Luận văn tốt nghiệp với đề tài: "Nghiên cứu phương pháp quản trị rủi ro

hướng mục tiêu và thử nghiệm ứng dụng trong xây dựng cổng thông tin điện tử Bộ

GTVT" đã cơ bản hoàn thành.

Luận văn đã hoàn thành các nội dung sau:

- Tìm hiểu những khái niệm, phương pháp quản trị rủi ro trong dự án phần mềm

và dự án xây dựng cổng thông tin điện tử Bộ GTVT

- Tập trung vào phương pháp quản trị rủi ro hướng mục tiêu trong các dự án công

nghệ thông tin (phát triển phần mềm, triển khai phần hệ thống mạng và phần cứng).

Các kết quả chính đạt được trong đề tài:

- Đề tài tổng hợp những khái niệm nghiên cứu cơ bản, là để xác định rủi ro trong

hoạt động có ảnh hưởng đến chi phí dự án và thời gian thực hiện dự án. Phân tích

rủi ro sẽ tiến hành thông phương pháp quản trị rủi ro và hướng mục tiêu của nó.

- Xây dựng giải pháp ứng dụng phương pháp quản trị rủi ro hướng mục tiêu

trong quá trình thực hiện dự án xây dựng cổng thông tin điện tử Bộ GTVT, thử

nghiệm và đánh giá kết quả.

Trong quá trình thực hiện khi ứng dụng phương pháp quản trị rủi ro hướng

mục tiêu chắc chắn rằng trong điều kiện mức độ chi phí thấp cho bộ phận xây dựng,

theo dõi quản lý rủi ro hướng mục tiêu sẽ mang lại hiệu quả kinh tế cao đặc biệt

trong các dự án được xây dựng với thời gian dài ở những nơi thực hiện dự án còn

khó khăn chính vì vậy khi phần mềm này được hoàn chỉnh sẽ được nhiều nhà đâu tư

đón nhận để ứng dụng trong quá trình thực hiện dự án.

2. Hướng phát triển của đề tài.

Do điều kiện cá nhân còn những hạn chế, nên vấn đề nghiên cứu về "Nghiên

cứu phương pháp quản trị rủi ro hướng mục tiêu và thử nghiệm ứng dụng trong xây

dựng cổng thông tin điện tử Bộ GTVT " trong khuôn khổ của luận văn này chỉ dừng

lại ở những nghiên cứu ban đầu. Vì vậy, những nghiên cứu tiếp theo về vấn đề này

có thể tập trung triển khai theo các hướng như sau:

-Nghiên cứu phương pháp độ rủi ro trong dự án

- Nghiên cứu về kiểm tra đánh giá trong điều kiện khi sử dụng trong các dự án.

-Nghiên cứu về mức độ thích ứng khi sử dụng.

TÀI LIỆU THAM KHẢO

Tài liệu tham khảo tiếng Việt

[1] Công văn số 2589/BTTTT-ƯDCNTT ngày 24/08/2011 về việc hướng dẫn xác

định chi phí phát triển, nâng cấp phần mềm nội bộ.

[2] https://vi.wikipedia.org/wiki/R%E1%BB%A7i_ro

[3] Huỳnh Quyết Thắng, Kinh tế công nghệ phần mềm, NXB Bách Khoa Hà Nội, 2016

[4] Slide Kinh tế kỹ thuật công nghệ phần mềm, PGS.TS Huỳnh Quyết Thắng

Tài liệu tham khảo tiếng Anh

[5] S. Islam, M. A. Joarder, and S. H. Houmb. Goal and risk factors in offshore outsourced

software development from vendor’s viewpoint. In ICGSE ’09: Proceedings of the 2009

Fourth IEEE International Conference on Global Software Engineering, pages 347–352,

Washington, DC, USA, 2009. IEEE Computer Society.

[6] S. Islam. Software development risk management model: a goal driven

approach. In ESEC/FSE Doctoral Symposium ’09: Proceedings of the doctoral

symposium for ESEC/FSE on Doctoral symposium, pages 5–8, New York, NY,

USA, 2009. ACM.

[7] W. Wu and T. Kelly. Combining bayesian belief networks and the goal structuring

notation to support architectural reasoning about safety. In Computer Safety, Reliability, and

Security, Lecture Notes in Computer Science, 2007.

[8] A. van Lamsweerde and E. Letier. Handling obstacles in goaloriented requirements

engineering. IEEE Transactions on Software Engineering, 26:978–1005, 2000.

[9] Project Management Institute, (2013), A Guide to the Project Management Body

of Knowledge (the PMBOK Guide) - Fifth Edition, 589 pages.

[10] Steve Tockey, 2004. Return on Software: Maximizing the Return on Your

Software Investment. Publisher: Prentice Hall PTR, 656 pages, 2004

[11] Taxonomy - Based Risk Identification - Software Engineering Institude (SEI) -

Carnegie Mellon University (http://www.sei.cmu.edu/)

[12] Williams, T. (2003). The Contribution of Mathematical Modeling to the Practice

of Project Management. IMA Journal of Management Mathematics, No.14, p. 3.