(LUẬN văn THẠC sĩ) 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​

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á

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

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

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

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

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

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)

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

- 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

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

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

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]

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á

Để 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

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

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

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ủ

ụ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

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

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]

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,