Xác định các yếu tố rủi ro ảnh hưởng đến thành công của dự án phần mềm tình huống nghiên cứu, công ty TNHH KMS technology việt nam

NGUYỄN THỊ PHƯƠNGXÁC ĐỊNH CÁC YẾU TỐ RỦI RO ẢNH HƯỞNG ĐẾN THÀNH CÔNG CỦA DỰ ÁN PHẦN MỀM TÌNH HUỐNG NGHIÊN CỨU: CÔNG TY TNHH KMS TECHNOLOGY VIỆT NAM Chuyên Ngành: Quản Trị Kinh Doanh LUẬN

NGUYỄN THỊ PHƯƠNG

XÁC ĐỊNH CÁC YẾU TỐ RỦI RO ẢNH HƯỞNG ĐẾN THÀNH CÔNG CỦA DỰ ÁN PHẦN MỀM

TÌNH HUỐNG NGHIÊN CỨU:

CÔNG TY TNHH KMS TECHNOLOGY VIỆT NAM

Chuyên Ngành: Quản Trị Kinh Doanh

LUẬN VĂN THẠC SĨ KINH TẾ

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

PGS-TS VÕ THỊ QUÝ

TP Hồ Chí Minh – Năm 2012

LỜI CAM ĐOAN

Kính thưa Quý thầy cô, kính thưa Quý độc giả,

Tôi tên là Nguyễn Thị Phương, là học viên Cao học khoá 18 – Lớp Quản trị Kinh Doanh K18 – Trường Đại học Kinh tế Tp HCM (MSSV : 7701080867).

Tôi xin cam đoan luận văn nghiên cứu sau đây là do bản thân tôi thực hiện.

Cơ sở lý luận là tham khảo từ các tài liệu thu thập được từ sách, báo, các nghiên cứu đã được nêu trong phần tài liệu tham khảo Dữ liệu phân tích trong luận văn là thông tin thu thập thông qua phỏng vấn trực tiếp những nhân viên chủ chốt tại doanh nghiệp phần mềm KMS Technology.

Tôi cam đoan đề tài này không hề sao chép từ các công trình nghiên cứu khoa học nào khác.

Tp.Hồ Chí Minh, ngày 27 tháng 12 năm 2012.

Học viên

Nguyễn Thị Phương

LỜI CẢM ƠNSau một thời gian nỗ lực, tôi đã hoàn thành đề tài “Xác định các yếu tố rủi

ro ảnh hưởng đến thành công của dự án phần mềm Tình huống nghiên cứu :Công ty TNHH KMS Technology Việt Nam” Trong suốt quá trình thực hiện, tôi

đã nhận được sự hướng dẫn và hỗ trợ thông tin nhiệt tình từ quý thầy cô, bạn bè,người thân Vì vậy, tôi xin phép được gửi lời cảm ơn sâu sắc đến :

- TS Võ Thị Quý, là giáo viên hướng dẫn luận văn cho tôi trong suốt quá trình thực hiện đề cương cho đến khi hoàn tất luận văn Đề tài này sẽ không thể hoàn thành nếu không có sự hướng dẫn nhiệt tình của cô.

- Cảm ơn các anh chị đồng nghiệp tại công ty KMS Technology đã nhiệt tình hỗ trợ và tư vấn, giúp đỡ tôi trong quá trình thu thập dữ liệu để

phân tích.

- Và cuối cùng, cảm ơn chồng tôi Nguyễn Văn Đoan đã động viên, ủng

hộ tinh thần và tạo mọi điều kiện tốt nhất cho tôi hoàn thành luận văn kịp thời hạn quy định.

Tp.Hồ Chí Minh, ngày 27 tháng 12 năm 2012.

Học viên

Nguyễn Thị Phương

MỤC LỤC

LỜI CAM ĐOAN i

MỤC LỤC iii

DANH MỤC CÁC BẢNG BIỂU vi

DANH MỤC CÁC HÌNH viii

DANH MỤC CÁC TỪ NGỮ VIẾT TẮT ix

MỞ ĐẦU 1

1 Giới thiệu lý do chọn đề tài 1

2 Câu hỏi nghiên cứu 2

3 Mục tiêu nghiên cứu 2

4 Phạm vi, giới hạn của nghiên cứu 2

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

6 Ý nghĩa thực tiễn của nghiên cứu 3

7 Cấu trúc đề tài 3

CHƯƠNG 1 – CƠ SỞ LÝ THUYẾT 4

1.1 Tổng quan 4

1.2 Các khái niệm cơ bản 5

1.2.1 Dự án 5

1.2.2 Khái niệm thành công dự án 6

1.2.3 Vòng đời của dự án phần mềm 6

1.2.4 Rủi ro 8

1.3 Các yếu tố rủi ro ảnh hưởng đến dự án phần mềm 9

1.3.1 Nhóm rủi ro về sự quản lý của các thành phần hữu quan 14

1.3.2 Nhóm rủi ro về yêu cầu và lịch trình 16

1.3.3 Nhóm rủi ro về quản lý dự án 19

1.3.4 Nhóm rủi ro về môi trường phát triển 22

1.4 Phương pháp nghiên cứu Delphi 23

1.4.1 Lịch sử hình thành 23

1.4.2 Phương pháp Delphi 23

1.4.3 Quy trình tiến hành phương pháp Delphi 24

1.4.4 Số vòng phỏng vấn trong phương pháp Delphi 26

1.4.5 Câu hỏi phỏng vấn trong phương pháp Delphi 26

1.4.6 Sự đồng thuận trong phương pháp Delphi 27

1.4.7 Các chuyên gia trong phương pháp Delphi 28

1.4.8 Sử dụng phương pháp Delphi 29

1.4.9 Hạn chế của phương pháp Delphi 29

1.4.10 So sánh phương pháp Delphi và phương pháp chuyên gia 30

1.5 Tóm tắt chương 1 31

CHƯƠNG 2 – GIỚI THIỆU CÔNG TY KMS TECHNOLOGY 32

2.1 Giới thiệu chung về công ty KMS TECHNOLOGY 32

2.2 Các dịch vụ chiến lược của KMS TECHNOLOGY 33

2.3 Nguồn lực của KMS TECHNOLOGY 34

2.4 Quy trình phát triển phần mềm và chất lượng dịch vụ của KMS 34

2.5 Các dự án đã hoàn thành trong năm 2011 và quý I, II năm 2012 35

2.5.1 Dự án Livescribe 35

2.5.2 Dự án HMS (Health Market Science) 36

2.5.3 Dự án MarketLive 36

2.5.4 Dự án Alere 36

2.5.5 Dự án Invivodata 37

2.6 Tóm tắt chương 2 37

CHƯƠNG 3 – PHÂN TÍCH KẾT QUẢ KHẢO SÁT 38

3.1 Xác định các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu quan 38

3.2 Xác định các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình 43

3.3 Xác định các yếu tố thuộc nhóm rủi ro về môi trường phát triển 48

3.4 Xác định các yếu tố thuộc nhóm rủi ro về quản lý dự án 52

3.5 Tóm tắt chương 3 58

KẾT LUẬN 59

4.1 Kiến nghị 59

4.2 Hạn chế và gợi ý cho các nghiên cứu tiếp theo 61

TÀI LIỆU THAM KHẢO 62

Tài liệu tiếng Việt 62

Tài liệu tiếng Anh 62

PHỤ LỤC 1 – CÂU HỎI NGHIÊN CỨU 66

PHỤ LỤC 2 – KẾT QUẢ PHỎNG VẤN 67

PHỤ LỤC 3 – DANH SÁCH CÁC CHUYÊN GIA 69

DANH MỤC CÁC BẢNG BIỂU

Bảng 1-1: Tóm tắt các yếu tố rủi ro theo Sharma, 2008

Bảng 3-1: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 1Bảng 3-2: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 2Bảng 3-3: Tỉ lệ khác biệt các yếu tố của nhóm thành phần hữu quan giữa vòng 2 và 1Bảng 3-4: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 3Bảng 3-5: Tỉ lệ khác biệt các yếu tố của nhóm các thành phần hữu quan giữa vòng 3, 2Bảng 3-6: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 4Bảng 3-7: Tỉ lệ khác biệt các yếu tố của nhóm các thành phần hữu quan giữa vòng 4, 3

các vòng

Bảng 3-9: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 1Bảng 3-10: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 2Bảng 3-11: Tỉ lệ khác biệt các yếu tố về về yêu cầu và lịch trình giữa vòng 2 và 1Bảng 3-12: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 3Bảng 3-13: Tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa vòng 3 và vòng 2Bảng 3-14: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 4Bảng 3-15: Tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa vòng 4 và vòng 3Bảng 3-16: Tóm tắt tỉ lệ khác biệt các yếu tố về sự quản lý các bên liên quan giữacác vòng

Bảng 3-17: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 1Bảng 3-18: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 2Bảng 3-19: Tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa vòng 2 và 1Bảng 3-20: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 3Bảng 3-21: Tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa vòng 3 và 2Bảng 3-22: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 4Bảng 3-23: Tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa vòng 4 và 3

Bảng 3-24: Tóm tắt tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa các vòng

Bảng 3-25: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 1

Bảng 3-26: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 2

Bảng 3-27: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 2 và vòng 1Bảng 3-28: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 3Bảng 3-29: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 3 và vòng 2Bảng 3-30: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 4Bảng 3-31: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 4 và vòng 3Bảng 3-32: Tóm tắt tỉ lệ khác biệt các yếu tố về quản lý dự án giữa các vòngBảng 3-33: Tóm tắt các yếu tố rủi ro đƣợc xác định

BA Business Analysist Nhân viên phân tích yêu cầu khách hàng

QA Quality Asurance Nhân viên đảm bảo chất lƣợng

MỞ ĐẦU

1 Giới thiệu lý do chọn đề tài

Công nghệ thông tin đóng vai trò quan trọng trong cuộc sống của chúng tangày nay Công nghệ thông tin góp phần vào sự tăng trưởng và phát triển của đấtnước Bên cạnh những thuận lợi do ngành công nghệ thông tin mang lại, vẫn tồn tạimột số lượng lớn các dự án phần mềm thất bại, vượt chi phí, trễ hạn, độ tin cậykém và không thỏa mãn người dùng Theo nghiên cứu của Standish Group, trên thếgiới có 44% dự án phần mềm được gọi là thách thức (trễ hạn, vượt chi phí haythiếu những tính năng cần thiết), trong khi có 24% dự án thất bại (hủy bỏ trước khihoàn thành hoặc được giao và không bao giờ được sử dụng) Như vậy, tổng cộng

chịu trễ tiến độ hoặc vượt chi phí hay không đáp ứng các mục tiêu của dự án Tỷ lệthất bại cao của các dự án phần mềm có thể là do đặc tính rất cơ bản của bản thânphần mềm Các dự án phần mềm là tập hợp của các chương trình lớn với các tươngtác và phụ thuộc chức năng; liên quan đến việc tạo ra một sản phẩm mà chưa baogiờ được tạo ra trước đó Dự án phần mềm nói chung là phức tạp và việc phát triểncủa dự án diễn ra trong một môi trường năng động, điều kiện kinh doanh và côngnghệ thay đổi trong quá trình thực hiện dự án Người sử dụng thường không chắcchắn về nhu cầu của họ và thường xuyên thay đổi yêu cầu khi dự án đang thựchiện Kết quả là các dự án phần mềm bị vượt chi phí, trễ tiến độ, độ tin cậy kém và

Đã có nhiều nguyên cứu xác định nguyên nhân của thất bại và chậm trễ trong

dự án phần mềm Những nguyên nhân này được gọi là rủi ro ảnh hưởng đến dự án

chẳng hạn như mức tiêu hao sức lực cao, thiếu hỗ trợ quản lý cấp cao, sự hiểu lầm

về yêu cầu, tình trạng thiếu hụt nhân sự, ước lượng sai … có ảnh hưởng đến kếtquả thành công của dự án, dẫn đến sự chậm trễ và thất bại của dự án

phát triển và áp dụng rộng rải, do đó chúng ta chưa có những chuẩn mực xác định đượccác yếu tố rủi ro ảnh hưởng đến thành công của dự án phần mềm

Vì thế, học viên đề xuất đề tài “Xác định các yếu tố rủi ro ảnh hưởng đến thành công của dự án phần mềm, tình huống nghiên cứu: công ty TNHH KMS Technology”

2 Câu hỏi nghiên cứu

Đề tài được thực hiện nhằm trả lời cho câu hỏi nghiên cứu sau đây:

tình huống nghiên cứu: công ty KMS Technology Việt Nam

3 Mục tiêu nghiên cứu

Thông qua phỏng vấn các chuyên gia đang làm việc toàn thời gian tại KMS Technology, đề tài nghiên cứu được thực hiện nhằm:

tại KMS Technology

- Đưa ra các biện pháp kiến nghị để hạn chế các rủi ro và nâng cao tỉ lệ thành

công của các dự án trong tương lai

4 Phạm vi, giới hạn của nghiên cứu

Phạm vi khảo sát trong nghiên cứu này chỉ giới hạn đối với các dự án phầnmềm đã hoàn thành năm 2011 và quý I, II năm 2012 tại công ty KMS TechnologyViệt Nam Việc áp dụng cho thành phố Hồ Chí Minh hay toàn lãnh thổ Việt Nam sẽthuộc về các nghiên cứu khác trong tương lai

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

Phương pháp nghiên cứu định tính được dùng trong luận văn Dữ liệu thuthập thông qua phỏng vấn trực tiếp, chat, email Dữ liệu thu thập được xử lý và từ

đó xác định được các yếu tố rủi ro ảnh hưởng đến thành công của dự án phần mềm

6 Ý nghĩa thực tiễn của nghiên cứu

Đề tài nghiên cứu mang đến ý nghĩa thực tiễn cho công ty KMS Technology

vì nó bổ sung kiến thức cho các nhà quản lý dự án, có cái nhìn tổng quan về các yếu

tố rủi ro ảnh hưởng trực tiếp đến dự án của doanh nghiệp mình và từ đó rút ra cáchthức kiểm soát tác động của rủi ro tới dự án phần mềm để đảm bảo sự thành côngcủa dự án trong tương lai

7 Cấu trúc đề tài

Luận văn bao gồm các chương sau:

phương pháp nghiên cứu cũng như cấu trúc và tóm tắt của luận văn

phần mềm, thành công của dự án phần mềm Đồng thời chương này cũng trình bày

về phương pháp nghiên cứu Delphi được sử dụng trong luận văn

thành trong năm 2011 và quý I, II năm 2012

thức (trễ hạn, vượt chi phí hay thiếu những tính năng cần thiết), trong khi có 24%

dự án thất bại (hủy bỏ trước khi hoàn thành hoặc được giao và không bao giờ được

sử dụng) Như vậy, tổng cộng 68% số dự án là không thành công hoặc thách thức,

khi các dự án còn lại phải chịu trễ tiến độ hoặc vượt chi phí hay không đáp ứng cácmục tiêu của dự án

Các dự án phần mềm là tập hợp của các chương trình lớn với các tương tác

và phụ thuộc chức năng; liên quan đến việc tạo ra một sản phẩm mà chưa bao giờđược tạo ra trước đó Kết quả là các dự án phần mềm dễ bị vượt chi phí, trễ tiến

đoán sự thành công của dự án vì phạm vi của dự án thay đổi liên tục tùy thuộc vàothị trường; do đó các nguồn lực phải được tái phân bổ dẫn đến trễ tiến độ và vượtchi phí Các dự án phần mềm thường liên quan đến nhiều thực thể như công ty,phòng ban, cá nhân …Và thường có cảm giác không có liên hệ giữa các nhân viên

phát triển dự án phần mềm ẩn chứa nhiều rủi ro Vì vậy, quản lý những rủi ro liênquan là quan trọng hàng đầu trong việc phát triển dự án phần mềm, đặc biệt là trongcác dự án phần mềm quy mô lớn Nếu rủi ro không được kiểm soát ở giai đoạn đầucủa dự án, nó sẽ gây ra một sự gia tăng theo cấp số nhân trong chi phí của dự án

Hình 1-1: Mối liên hệ giữa rủi ro dự án với chi phí/lợi nhuận

1.2 Các khái niệm cơ bản

1.2.1 Dự án

Dự án là một quá trình gồm các công tác, nhiệm vụ có liên quan với nhau,được thực hiện nhằm đạt được mục tiêu đã đề ra trong điều kiện ràng buộc về thời

thời trong điền kiện nhân lực, tài nguyên và tài chính của tổ chức để thực hiện cácyêu cầu kỹ thuật, phạm vi công việc trong mối quan hệ ràng buộc thời gian và chiphí để đạt được lợi ích, được xác định bởi mục tiêu số lượng và chất lượng

Dự án phần mềm là dự án trong đó phạm vi duy nhất của công việc với cácthông số kỹ thuật nhất định mà cần phải được hoàn thành trong một thời gian nhất

mềm là khách hàng, là người sẽ sử dụng hệ thống cho các mục đích kinh doanh củamình Đối tượng quan trọng thứ hai của một dự án phần mềm là các nhân viên thamgia thực hiện dự án, người xây dựng hệ thống phần mềm

1.2.2 Khái niệm thành công dự án

Một dự án được gọi là thành công khi hoàn thành đúng tiến độ, nằm trongngân sách được duyệt, phù hợp với các chỉ tiêu kỹ thuật đã đề ra, và làm thỏa mãn

Đánh giá dự án được gọi là thành công hay thất bại còn phụ thuộc vào sựcảm nhận của các bên liên quan Cùng kết quả đầu ra của dự án, nhưng đánh giáthành công của mỗi bên tham gia khác nhau vì mục tiêu và sự ưu tiên được xác

đánh giá thành công của dự án trên quan điểm của các nhân viên tham gia thực hiện

dự án, người xây dựng hệ thống được sử dụng bởi khách hàng

1.2.3 Vòng đời của dự án phần mềm

Trước khi tìm hiểu những rủi ro tác động đến sự thành công của các dự ánphần mềm, cần thiết phải hiểu được các giai đoạn của vòng đời phát triển phầnmềm

Vòng đời của dự án phát triển phần mềm (Software Development Life Cycle–SDLC) là một khuôn khổ được sử dụng để hiểu và phát triển các hệ thống thôngtin và phần mềm thành công Đó là một quá trình được sử dụng bởi hầu như tất cảcác nhân viên lập trình và các công ty phát triển phần mềm như là tiêu chuẩn trongquá trình phát triển phần mềm SDLC có nhiều mô hình và mỗi mô hình có nhữngđiểm mạnh, điểm yếu của nó, ưu và nhược điểm riêng

Các hoạt động tiêu biểu liên quan đến vòng đời phát triển phần mềm bao gồm:

Hình 1-2: Vòng đời của dự án phần mềm

Thu thập yêu cầu: xác định rõ các yêu cầu là bước đầu tiên trong quá trình

phát triển phần mềm Yêu cầu hệ thống có thể thay đổi tùy thuộc vào các sản phẩmphần mềm sẽ được phát triển Vì vậy, cần phải phân tích cẩn thận các yêu cầu cần

Phân tích yêu cầu: bước này nghiên cứu tính khả thi về các yêu cầu thu

thập được trong bước đầu tiên Trong giai đoạn này, nhân viên lập trình phải giao

tiếp với khách hàng và phân tích các yêu cầu và hệ thống của họ Trong giai đoạnnày cũng cần chuẩn bị kế hoạch hoặc tiến độ của dự án, chi phí ước tính cho việcphát triển và thực hiện hệ thống, ngày giao hàng dự tính cho mỗi giai đoạn của quátrình phát triển hệ thống Giai đoạn này là nền tảng của quá trình phát triển phầnmềm, các bước tiếp theo trong SDLC sẽ dựa trên các phân tích được thực hiện

Phân tích hệ thống và thiết kế: đây là một giai đoạn quan trọng trong phát

triển phần mềm Các phân tích được thực hiện và các thiết kế của hệ thống sẽ đượcphát triển như thiết kế cơ sở dữ liệu, thiết kế đặc tả chức năng, thiết kế tài liệu ….Cần phải chuẩn bị các tài liệu thiết kế bởi vì giai đoạn tiếp theo, cụ thể là giai đoạnphát triển, dựa trên các tài liệu thiết kế này để thực hiện Khi cấu trúc của tài liệu vàcác phân tích được chuẩn bị tốt, nó sẽ làm giảm thời gian thực hiện trong các bước

Giai đoạn phát triển (lập trình): đây là giai đoạn mà phát triển phần mềm

thực sự diễn ra Giai đoạn này dựa trên các tài liệu thiết kế được chuẩn bị trong giaiđoạn trước đó Mã được viết bằng ngôn ngữ lập trình đã chọn Các mã sẽ được

Kiểm thử: đây là giai đoạn đảm bảo chất lượng của phần mềm, đảm bảo

phần mềm được giao không có lỗi Điều này được xác định bằng cách kiểm tra mãphát triển Các công cụ và kỹ thuật khác nhau dùng để kiểm tra ở các cấp độ khácnhau như kiểm tra hồi quy, kiểm tra hiệu suất … Dựa trên nhu cầu, các phươngpháp kiểm thử được lựa chọn và báo cáo lỗi Sau quá trình này, các nhân viên lậptrình một lần nữa đi vào giai đoạn phát triển để sửa lỗi và kiểm thử một lần nữa

Triển khai: đây là một trong những giai đoạn cuối cùng của SDLC Trong

Hỗ trợ, bảo trì và nâng cấp: đây là giai đoạn cuối của SDLC Và là một

quá trình không ngừng: khi môi trường thay đổi, các vấn đề mới được phát hiện vàyêu cầu mới được xác định, tính năng mới cần được thêm vào các phần mềm hiện

Toàn bộ vòng đời của dự án phát triển phần mềm liên tục tiếp xúc với cả rủi

ro nội bộ và bên ngoài Những rủi ro có mặt trong tất cả các giai đoạn của SDLC vàtrách nhiệm của người quản lý dự án hoặc là loại bỏ hoặc làm giảm tác động của nóđối với dự án Các loại rủi ro khác nhau của dự án phần mềm sẽ được thảo luậndưới đây

1.2.4 Rủi ro

Có rất nhiều khái niệm về rủi ro, mỗi tác giả lại đưa ra một định nghĩa khácnhau về rủi ro

Trong dự án phần mềm, rủi ro được định nghĩa như sau:

thích theo định nghĩa này

1.3 Các yếu tố rủi ro ảnh hưởng đến dự án phần mềm

Đã có rất nhiều nghiên cứu xác định, phân tích rủi ro trong dự án phần mềm.Các nhà nghiên cứu đã xác định rất nhiều yếu tố rủi ro ảnh hưởng đến thành côngcủa dự án phần mềm

có kinh nghiệm đã xác định mười yếu tố rủi ro ảnh hưởng nhiều nhất đến thành công của

dự án phần mềm Đó là: (1) thiếu hụt nhân sự, (2) lịch trình và ngân sách không thực tế,(3) phát triển sai các chức năng, (4) phát triển giao diện người dùng

sai, (5) vượt phạm vi đề ra, (6) khách hàng thay đổi yêu cầu liên tục, (7) thiếucông cụ thực hiện dự án, (8) phân công công việc không hiệu quả, (9) hiệu suấtlàm việc kém, (10) căng thẳng trong công việc

án thành công: hiểu sai yêu cầu của khách hàng, xác định sai phạm vi dự án, quản lýkém, sự thay đổi trong việc chọn kỹ thuật, nhu cầu kinh doanh thay đổi, thời hạn khôngthực tế, sự phản đối của người sử dụng, mất nguồn tài trợ, thiếu nhân viên có kinhnghiệm, nhà quản lý không chịu rút kinh nghiệm từ những sai lầm

nhà quản lý dự án nhiều kinh nghiệm từ Mỹ, HongKong, Phần Lan, đã đưa ra các

yếu tố rủi ro ảnh hưởng nhiều nhất đến thành công của dự án phần mềm Danh sách rủi ro bao gồm:

người dùng và thất bại trong việc đạt được cam kết của người dùng, nhà quản lý thiếu

kỹ năng

ảnh hưởng đến chi phí và lịch trình dự án

kỹ năng và kiến thức cần thiết, nhân sự không đủ hoặc không phù hợp

Tuy nhiên, những phân tích này không liên hệ với vòng đời phát triển dự án

phần mềm và sử dụng kỹ thuật Delphi để xác định các yếu tố rủi ro tiêu biểu Các yếu tố

đó là:

 Thất bại trong việc đạt được cam kết của người dùng

 Hiểu sai yêu cầu của khách hàng

 Thiếu sự tham gia của người dùng

 Nhân viên thiếu kỹ năng và kiến thức cần thiết

 Quản lý sự thay đổi yêu cầu kém

 Thay đổi phạm vi hay mục tiêu của dự án

 Sử dụng công nghệ mới

 Không quản lý mong đợi của người sử dụng cuối cùng

 Nhân sự không phù hợp hoặc không đủ

 Xung đột trong nội bộ khách hàng.

liên quan đến các đặc điểm khác nhau của một dự án phát triển phần mềm được phát

công nghệ sử dụng, không đủ nguồn lực, nhóm làm việc thiếu chuyên môn, thiếu sự hỗtrợ của người dùng, người sử dụng thiếu kinh nghiệm, quyền lực và trách nhiệm của cácbên không được xác định rõ ràng, cường độ của các cuộc xung đột (trong nội bộ kháchhàng hay giữa khách hàng với doanh nghiệp) là chín

yếu tố rủi ro hàng đầu mà một dự án phần mềm có thể gặp phải

án phần mềm: thiếu cam kết của quản lý cấp cao, hiểu sai yêu cầu của khách hàng,rào cản ngôn ngữ, thiếu quản lý dự án ở phía khách hàng, quản lý kém mong muốncủa người dùng, nhân viên thiếu kỹ năng và kiến thức cần thiết

Hình 1-3: Tóm tắt các yếu tố rủi ro của các nhà nghiên cứu

Như vậy, có rất nhiều nghiên cứu đã thực hiện để xác định các rủi ro trong

dự án phần mềm Các phương pháp khác nhau đã được sử dụng để đưa ra danhsách các yếu tố rủi ro quan trọng Kết quả là, đã có danh sách các yếu tố rủi ro khácnhau với một số điểm tương đồng và một số khác biệt Một số yếu tố rủi ro chỉ ảnhhưởng đến các dự án cụ thể trong điều kiện cụ thể Tuy nhiên, một số yếu tố đượcbáo cáo là rất thường gặp và có tác động mạnh đến thành công của dự án Một sốyếu tố rủi ro có thể kiểm soát trong khi những yếu tố rủi ro khác không thể đượckiểm soát bởi người quản lý dự án

diện bao gồm tất cả các yếu tố rủi ro ảnh hưởng đến các dự án phần mềm Các rủi

ro này được chia làm 4 nhóm: nhóm rủi ro về sự quản lý của các thành phần hữuquan, nhóm rủi ro về yêu cầu và lịch trình, nhóm rủi ro về môi trường phát triển dự

án, nhóm rủi ro về quản lý dự án

Rủi ro

Khả năng kiểm soát rủi ro

Hình 1-4: Các nhóm rủi ro trong dự án phần mềm

Bảng 1-1: Tóm tắt các yếu tố rủi ro theo Sharma, 2008

Thiếu cam kết của quản lý cấp cao

Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án

Truyền thông sai lệch về các yêu cầu của khách hàng

Phạm vi, mục tiêu của dự án không rõ ràng

Yêu cầu của khách hàng thường xuyên thay đổi

Nhóm rủi ro về Việc quản lý thay đổi không đúng cách

yêu cầu và lịch Lịch trình và ngân sách không thực tế

trình

Hiểu sai yêu cầu của khách hàng

Mong muốn của khách hàng không thực tế

Thực hiện các công việc phụ thêm ngoài dự án (gold plating)

Thiên tai

Nhóm rủi ro Các yếu tố

Lập kế hoạch không đầy đủ

Thiếu phương pháp quản lý dự án

Sử dụng kỹ thuật mới

Thiếu phân công trách nhiệm rõ ràng

Nhóm rủi ro về Thiếu kiến thức về kỹ thuật

quản lý dự án

Phân bố nhân sự không phù hợp

Nhân viên nghỉ việc

Thiếu sự cam kết của các thành viên thực hiện dự án

Thiếu công cụ đo lường sự tin cậy

Thiếu công cụ để xác nhận và kiểm thử

1.3.1 Nhóm rủi ro về sự quản lý của các thành phần hữu quan

Nhóm này cho thấy rằng các dự án thường thành công khi có sự cam kết của cảquản lý cấp cao và người dùng cuối, tức là những người thực sự sẽ sử dụng hệ thống.Nếu không có điều lệ, nhiệm vụ rõ ràng, dự án chỉ đơn giản là không khả thi Thiếu sựcam kết của cả quản lý cấp cao và người sử dụng là một rủi ro cao Nhưng cam kếtban đầu là không đủ Khi một dự án đã bắt đầu, quản lý dự án phải định kỳ đánh giámức độ cam kết của các quản lý cấp cao và người sử dụng để tránh gặp tình huống màcác sự hỗ trợ cho các dự án đột nhiên bị cắt Những rủi ro này thuộc nguy cơ cao vàkhó kiểm soát bởi người quản lý dự án Quản lý dự án phải thực hiện các bước hợp lý

để đảm bảo rằng họ có sự hỗ trợ và cam kết cần thiết để cung cấp một dự án thànhcông Danh sách các rủi ro thuộc thể nhóm này là:

1.3.1.1 Thiếu cam kết của quản lý cấp cao

Dự án có thể bị gián đoạn nếu không có sự hỗ trợ của quản lý cấp cao cho bộphận mình Sự hỗ trợ của quản lý doanh nghiệp trong việc cung cấp tài chính vàủng hộ cho những thành viên trong dự án rất quan trọng Nếu quản lý doanhnghiệp không hỗ trợ cho dự án, tạo áp lực thời gian thì rất khó phát triển Quản lýdoanh nghiệp có ít khả năng để đánh giá giá trị của dự án, các công việc khác và có

xu hướng tiết kiệm chi phí Nhiều dự án thất bại vì tiết kiệm chi phí mà cắt bỏ

quản lý cấp cao là rủi ro quan trọng nhất tác động đến các dự án phần mềm Sự hỗtrợ quản lý cấp cao là cần thiết trong suốt quá trình thực hiện dự án và quản lý cấpcao cần phải công khai và xác định rõ ràng các dự án ưu tiên hàng đầu

1.3.1.2 Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án

Văn hóa doanh nghiệp có thể gây bất lợi cho dự án do phe phái trong công

ty, văn hóa tổ chức thay đổi liên tục hoặc có nguy cơ thay đổi, và các ưu tiên nội

bộ khác Tất cả điều này sẽ dẫn đến việc hỗ trợ quản lý yếu kém và thất bại của dự

1.3.1.3 Thiếu sự tham gia của người dùng

Rủi ro này đã được nhiều lần đề cập bởi các nhà nghiên cứu khác nhau Rủi

ro này có trong mười nguyên nhân hàng đầu gây thất bại cho dự án phần mềm củanhiều nghiên cứu Nếu khách hàng không tham gia vào dự án, nó sẽ dẫn đến việcgiải thích sai về phạm vi và mục tiêu của dự án và do đó có thể dẫn đến mất tiền,

1.3.1.4 Khách hàng thiếu trách nhiệm và cam kết

Rủi ro này cũng là rủi ro cơ bản trong danh sách được xác định bởi Keil và

các nhân viên lập trình giả định các chức năng và yêu cầu kinh doanh, dẫn đến mụctiêu của dự án không đạt được Đây là lỗi do sự thiếu trách nhiệm của khách hàngtrong quản lý dự án

1.3.1.5 Xung đột giữa khách hàng và nhà thầu

Thù oán hay hận thù cá nhân có thể xảy ra giữa khách hàng và các nhà thầuphần mềm như là một kết quả của sự hiểu lầm, bất ngờ thay đổi phạm vi của hợp

đồng, giao hàng bị trì hoãn, hoặc một số tranh chấp khác giữa khách hàng và nhà

1.3.2 Nhóm rủi ro về yêu cầu và lịch trình

Nhiều dự án phải đối mặt với sự không chắc chắn và bất ổn về yêu cầu củasản phẩm Một số điểm không chắc chắn này có thể chấp nhận được trong giai đoạnđầu, rủi ro ảnh hưởng thành công của dự án càng tăng nếu các vấn đề đó khôngđược giải quyết khi dự án tiến triển Nếu các yêu cầu liên quan đến các yếu tố rủi rokhông được kiểm soát, nó có thể gây ra hoặc xây dựng các sản phẩm sai, hoặc xâydựng các sản phẩm kém chất lượng, dẫn đến việc khách hàng không hài lòng.Những rủi ro ở nhóm này có thể được kiểm soát bởi phần lớn người quản lý dự án,như giao tiếp khéo léo với người sử dụng hoặc khách hàng Những rủi ro thuộcnhóm này là:

1.3.2.1 Truyền thông sai lệch về các yêu cầu

Đôi khi chính các khách hàng không chắc chắn những gì họ mong muốn từ

dự án Rủi ro này có thể bị ảnh hưởng bởi sự hiểu lầm về yêu cầu của nhà thầuhoặc khách hàng, hay mong đợi bất thành văn của khách hàng, hoặc đặc điểm kỹthuật mà người sử dụng cuối cùng không đưa vào Mâu thuẫn có thể xảy ra giữacác người dùng càng đẩy mạnh vấn đề truyền thông sai lệch về các yêu cầu.Truyền thông sai lệch về các yêu cầu là một trong những yếu tố rủi ro lớn nhất vìtruyền thông sai lệch có thể làm phức tạp việc truyền tải các thiết lập ban đầu của

1.3.2.2 Phạm vi, mục tiêu dự án không rõ ràng

triển phần mềm có các mục tiêu khác nhau, thường xung đột với các mục tiêu củacác bên liên quan khác.Ví dụ, người dùng yêu cầu một hệ thống thân thiện vớingười sử dụng, tốc độ nhanh với nhiều chức năng có thể hỗ trợ nhiệm vụ của họ.Trong khi, các nhân viên lập trình hy vọng gặp phải những thách thức kỹ thuật thú

vị Những kỳ vọng khác nhau tạo ra xung đột cơ bản khi đồng thời tiếp cận Kếtquả là phạm vi không rõ ràng hoặc hiểu sai phạm vi và mục tiêu của dự án Hơn

nữa, việc xác định không rõ ràng các thông số kỹ thuật làm yêu cầu không có tínhhữu dụng, gây ra độ lệch về cả mốc thời gian và ngân sách

1.3.2.3 Thường xuyên thay đổi yêu cầu

Các bên liên quan (bao gồm cả người dùng) liên tục thay đổi các chức năngcủa phần mềm trong suốt vòng đời dự án Khi thay đổi các nhu cầu của người sử

nghị cố định một phần các chức năng và ngày giao hàng Cũng có lập luận rằng,các yêu cầu không nên cố định trong môi trường kinh doanh thay đổi nhanh chóngngày nay, một thiết kế cố định không thích hợp với thực tiễn kinh doanh Với mộtthiết kế cố định, các nhân viên lập trình có ít sự linh hoạt trong việc thay đổi cácthông số kỹ thuật Tuy nhiên thay đổi yêu cầu liên tục và không kiểm soát được sẽảnh hưởng lên chất lượng, chức năng, lịch trình, thiết kế, tích hợp và kiểm thử sảnphẩm; chắc chắn sẽ dẫn đến sự chậm trễ trong tiến độ dự án

1.3.2.4 Việc quản lý thay đổi không đúng cách

Nếu không có sự quản lý phù hợp trong việc thay đổi của phần mềm, cácdoanh nghiệp thiếu một sự hiểu biết đầy đủ về các phần mềm trong quy trình kinhdoanh của họ Điều này bao gồm quản lý sự thay đổi trong quá trình phát triểnphần mềm, thay đổi khi phần mềm đang được sử dụng, và các thay đổi liên quanđến yêu cầu, các mô hình, và các trường hợp thử nghiệm Điều này cũng bao gồmquản lý cả những thay đổi riêng lẻ và những thay đổi phụ thuộc Các nhà nghiêncứu cho rằng việc quản lý thay đổi không đúng cách là một trong những nguyên

1.3.2.5 Lịch trình và ngân sách không thực tế

Dự án không thể đạt được mục tiêu của nó khi ngân sách, chất lượng, tiến độ,mức độ thực hiện của dự án là không thực tế Dự án không đáp ứng các cam kết trongngân sách có thể dẫn đến việc phải ngừng dự án Các nhà nghiên cứu cho rằng, rủi ro

về lịch trình và thời gian là một trong những rủi ro quan trọng và phức tạp vì rất khó

để ước lượng lịch trình một cách chính xác và nhất quán Đối với các dự án lớn, độphức tạp càng cao thì việc ước lượng chính xác càng khó, dẫn đến

khó khăn trong việc lập lịch cho dự án Ropponen và Lyytinen [41] cho rằng rủi rotrong lập kế hoạch và thời gian sẽ được cải thiện với quản lý dự án có kinhnghiệm Một lịch trình cố định có thể dẫn đến áp lực tiến độ và những nhân viênchịu áp lực này không làm tốt những việc cần thiết, kết quả là không có khả năngtạo ra sản phẩm đạt yêu cầu.

1.3.2.6 Hiểu sai yêu cầu của khách hàng

Rất tốn thời gian và khó khăn để thu thập và ghi lại tất cả các yêu cầu chitiết từ tất cả các người dùng tiềm năng, kết quả nhóm dự án không biết đầy đủ vềnhững gì được yêu cầu để hoàn thành dự án thành công Điều này có thể dẫn đếnkhả năng phát triển một hệ thống không được sử dụng, bởi vì việc phân tích hệthống thích hợp để phát triển một tập hợp đầy đủ và chính xác các yêu cầu đãkhông được thực hiện Một số các nhà nghiên cứu đã xác định sự hiểu sai yêu cầu

[53]

1.3.2.7 Mong muốn của khách hàng không thực tế

sử dụng có thể xảy ra bất cứ khi nào mong đợi của người dùng không thực tế Điềunày xảy ra do lập kế hoạch không đầy đủ và không thu thập thông tin từ kháchhàng Đôi khi các nhóm dự án cũng được tiếp xúc với kỳ vọng không thực tế từquản lý cấp cao hoặc người quản lý dự án Những cản trở này dẫn đến các vấn đềnghiêm trọng trong các dự án phần mềm

1.3.2.8 Thực hiện các công việc phụ thêm ngoài dự án (gold plating)

Gold plating có nghĩa rằng nhóm nghiên cứu tập trung vào phân tích và làmviệc ở các mức độ chi tiết quá nhiều trong khi mất tầm nhìn của mục tiêu dự án.Thường thì các nhân viên lập trình và các nhà phân tích cho rằng khả năng bổsung hay thay đổi, được gọi là mạ vàng (gold plating), mà họ nghĩ rằng sẽ làm cho

hệ thống tốt hơn và hấp dẫn hơn theo quan điểm của họ Những sai lệch có thể dẫn

1.3.2.9 Ước lượng lịch trình và chi phí không chính xác

Một ước tính ban đầu không chính xác có thể dẫn đến việc phân bổ ngânsách , hoặc thời gian, hoặc cả hai không đầy đủ, gây thất bại cho dự án Ướclượng mọi khía cạnh của dự án, có các hành động hạn chế những việc có thể trongquá trình phát triển hoặc nâng cấp của một sản phẩm, và giới hạn các tùy chọn cósẵn Người ta tin rằng ước lượng phạm vi dự án dựa trên các kỹ thuật hoặc kinhnghiệm quản lý là không chính xác và các ước lượng thường dựa trên các giả địnhđơn giản và quá lạc quan, hoặc bi quan được thực hiện để phù hợp với những gìngười khác muốn nghe Không cần phải nói, ước lượng như vậy thường dẫn đếntai họa Nếu ước lượng có tính thực tế thấp, dự án sẽ bị thiếu nhân sự ngay từ đầu,

và tệ hơn nữa, là nhân viên phải làm thêm giờ quá mức hoặc kiệt sức Ngược lại,đánh giá quá cao một dự án cũng có thể có tác dụng tương tự như bất kỳ ước

1.3.3 Nhóm rủi ro về quản lý dự án

Nhóm rủi ro này liên quan đến việc thực hiện thực tế của dự án Quản lý dự

án có thể kiểm soát những rủi ro này, và do đó những rủi ro này được coi là vừaphải Trong những trường hợp bình thường, những rủi ro này không gây ra mối đedọa nghiêm trọng đối với dự án, do đó, chúng thuộc loại nguy cơ thấp Tuy nhiên,quản lý dự án không thể đủ khả năng xử lý hết những rủi ro này Thất bại trong việcquản lý rủi ro ở nhóm này có thể dẫn đến phần mềm kém chất lượng hoặc trễ hạnhay vượt ngân sách Những rủi ro sau đây thuộc về nhóm này:

1.3.3.1 Lập kế hoạch không đầy đủ

Kế hoạch không đầy đủ có thể làm cho toàn bộ dự án rối rắm Kế hoạch giúpxác định các kẽ hở trong dự án và người quản lý dự án có thể dùng các công cụ và

kỹ thuật để khắc phục những kẽ hở này Lập kế hoạch tỉ mỉ tại giai đoạn tiền dự ángiúp xác định rủi ro ở các giai đoạn đầu thực hiện Rủi ro này cũng được đề cập đến

1.3.3.2 Thiếu phương pháp quản lý dự án

Quản lý dự án kém được xem như là một nguyên nhân chính gây ra rủi ro vàthất bại trong dự án phần mềm Một kế hoạch đầy đủ và hoàn chỉnh có thể khôngnhất thiết phải được trình bày nhưng một chiến lược quản lý toàn diện và phù hợpvới định nghĩa rõ ràng về vai trò và trách nhiệm phải được thực hiện càng sớm càngtốt Theo các nhà nghiên cứu, yêu cầu thường xuyên không rõ ràng trong bất kỳ tàiliệu nào Quản lý dự án từ phía khách hàng thường thực hiện chuyển tiếp e-mail (vàchuyển tiếp một lần nữa, và một lần nữa) cho đến khi chúng đến các nhà cung cấp.Nên sau đó rất khó để tìm ra trách nhiệm, quản lý và nguồn lực cho mỗi yêu cầuthay đổi riêng biệt Vì vậy, xác định vai trò của các thành viên dự án và thiết lập

1.3.3.4 Thiếu phân công trách nhiệm rõ ràng

Đối với các dự án phần mềm lớn có đội ngũ lãnh đạo nhiều nhưng không cóphân công trách nhiệm rõ ràng, dẫn đến dự án không đáp ứng các mục tiêu của nó.Nếu mỗi nhóm trưởng đều liên lạc với khách hàng, nó có thể tạo ra một tình huống

1.3.3.5 Thiếu kiến thức về kỹ thuật

Nhân viên dự án có thể không có đủ kiến thức về công nghệ, hoặc kinh doanh,hoặc có thể chỉ cần không có kinh nghiệm để xử lý các dự án McLeod và Smith [35]

chỉ ra rằng, rủi ro phát sinh từ những người có kỹ năng không đầy đủ (cả về kỹ thuật

và quản lý) cũng như mức độ kinh nghiệm Việc thiếu kinh nghiệm với công nghệcũng làm tăng khả năng xảy ra rủi ro này Điều này là một trong những

1.3.3.6 Phân bố nhân sự không thích hợp.

Nhân viên dự án không phù hợp dẫn đến sự thất bại của dự án phần mềm.Một trong những lý do chính đằng sau là thiếu quy hoạch dự án và dự toán Nhânviên dư thừa sẽ dẫn đến tăng chi phí cho dự án, cũng như thiếu nhân viên sẽ dẫnđến kiệt sức nhân viên, tình trạng làm thêm giờ quá mức điều này gây tiêu hao sức

1.3.3.7 Nhân viên nghỉ việc

Nhân viên nghỉ việc trong quá trình thực hiện dự án có tác động tiêu cực rấtlớn, vì cực kỳ khó khăn để có thể tìm được người có đầy đủ kinh nghiệm kỹ thuậttrong một thời gian ngắn và hơn nữa, phải mất thời gian cho họ để thích nghi trongmột môi trường mới Những điều này có tác động tiêu cực đến năng suất của các dự

1.3.3.8 Thiếu sự cam kết của các thành viên thực hiện dự án

Thiếu cam kết từ các thành viên thực hiện dự án dẫn đến kết quả là hoạtđộng kém hiệu quả và cung cấp các sản phẩm chất lượng kém Các nghiên cứu đãxác nhận rằng thiếu cam kết từ các thành viên thực hiện dự án là do thiếu tin tưởng,

1.3.3.9 Thiếu công cụ đo lường sự tin cậy

Độ tin cậy được định nghĩa là xác suất của lỗi phần mềm trong quá trìnhhoạt động với một thời gian quy định trong một môi trường nhất định Độ tin cậy làmột thuộc tính quan trọng của chất lượng phần mềm, cùng với chức năng, hiệusuất, khả năng sử dụng, tiện dụng, cài đặt, bảo trì, và tài liệu Độ tin cậy phần mềmkhó đạt được Khó khăn của vấn đề bắt nguồn từ sự hiểu biết không đầy đủ về độtin cậy phần mềm và đặc điểm của phần mềm nói chung Hạn chế về thời gian và

1.3.3.10 Thiếu công cụ để xác nhận và kiểm thử

Phát triển và kiểm thử hệ thống là hai giai đoạn quan trọng nhất của bất kỳ

dự án phát triển phần mềm nào Các phương pháp và kỹ thuật lập trình và kiểm thửcần phải được chuẩn bị đầy đủ Việc sử dụng phần mềm và phần cứng không ổnđịnh và không tương thích có thể gây ra rủi ro đáng kể cho dự án Công cụ cần thiết

để xác nhận và kiểm thử các ứng dụng hoặc sản phẩm không thể thiếu cho việc thựchiện và triển khai thành công các phần mềm Nếu công cụ không có đúng lúc, nó có

1.3.4 Nhóm rủi ro về môi trường phát triển

Nhóm rủi ro này có thể xuất phát từ môi trường dự án tồn tại cả trong vàngoài tổ chức Những người quản lý dự án ít hoặc không có khả năng kiểm soátnhững rủi ro thuộc nhóm này Nhóm rủi ro này có khả năng xảy ra thấp, do đó,không được xem là rất quan trọng Tuy nhiên, nếu chúng xảy ra, có thể đe dọanghiêm trọng cho dự án Những rủi ro này rất khó khăn để dự đoán Những rủi rothuộc nhóm này là:

1.3.4.1 Hiệu quả làm việc của bên thứ 3 (third party)

Nhà thầu được lựa chọn không phù hợp với mục đích của dự án Nhà thầukhông thể cung cấp một giải pháp đáp ứng mục tiêu thời gian, chi phí, chất lượng

và hiệu suất Điều này có thể ảnh hưởng nghiêm trọng đến hiệu suất tổng thể của

dự án khi bất kỳ sự chậm trễ nào từ bên thứ ba có thể làm hỏng toàn bộ tiến độ dự

1.3.4.2 Cạnh tranh làm thay đổi lịch trình

Toàn cầu hóa đã làm nảy sinh những thách thức mới và một trong nhữngthách thức là phải theo kịp với các đối thủ cạnh tranh Đối thủ cạnh tranh có thể xâydựng các giải pháp phần mềm nhanh hơn, với nhiều chức năng hơn và chi phí rẻ

1.3.4.3 Thay đổi phạm vi do thay đổi mô hình kinh doanh

Với bất kì sự thay đổi môi trường nào, việc theo kịp tiến độ dự án là rất quantrọng Các nghiên cứu đã tìm ra rằng đôi khi do những thay đổi trong môi trườngcạnh tranh, phần mềm trở nên lỗi thời và không còn cần thiết cho người sử dụng

Theo một số nhà nghiên cứu, đầu tư kinh doanh trong lĩnh vực công nghệ thông tin

có thể bị ăn mòn do thay đổi điều kiện thị trường người tiêu dùng hoặc các tiến bộtrong công nghệ phần mềm Đôi khi, toàn bộ dự án có thể bị cắt giảm hoặc chấmdứt do thay đổi trong mô hình kinh doanh Nhà quản lý cấp cao có thể rút lại sự hỗtrợ cho dự án do chuyển dịch cơ cấu của doanh nghiệp hoặc khách hàng đột nhiên

1.3.4.4 Thiên tai

Thiên tai rất hiếm khi xảy ra nhưng nó là một trong các yếu tố rủi ro quantrọng nhất Thứ nhất vì nó không thể kiểm soát được và thứ hai nó có thể gây rathiệt hại hoàn toàn cho dự án dẫn đến mất tiền, mất thời gian và thậm chí tính

để dự báo và đề ra quyết định Khái niệm cơ bản của nó xuất hiện vào thập niên 50của thế kỷ trước, tại tổ chức RAND Corporation, là kết quả của công trình nghiêncứu được không quân Mỹ tài trợ, để tìm ra những phương thức đúng đắn trong việc

sử dụng những ý kiến tư vấn của các chuyên gia Quá trình điều tra khảo sát này sửdụng ý kiến của các chuyên gia để nhận dạng những phát triển công nghệ khả dĩtrong 10-20 năm tới và ước tính khả năng xảy ra cũng như thời gian thực thi

1.4.2 Phương pháp Delphi

Như chúng ta đã biết, rất khó để suy luận và tổng hợp kiến thức từ cácchuyên gia (Hwang và các đồng sự, 2006), đặc biệt với các kiến thức và chuyênngành khác nhau Để giải quyết vấn đề này, phương pháp Delphi là một phươngpháp tối ưu để thu thập kiến thức cho chuyên gia ở các thời điểm khác nhau, nhữngthời điểm này được cân nhắc lựa chọn trong khi việc xin ý kiến của các chuyên gia

đã được tiến hành (Chu and Hwang, 2007) Phương pháp cho phép tổng hợp có hệthống những đánh giá của chuyên gia về một chủ đề cụ thể thông qua một bản câuhỏi và được phản hồi liên tục với các thông tin sơ lược về các lựa chọn từ những sựphản hồi đầu tiên (Delbecq và các đồng sự, 1975) Delphi là một phương phápnghiên cứu định tính khá chính xác và có khả năng giải quyết các vấn đề nhằm gópphần trong việc ra quyết định và để đạt được sự nhất trí theo nhóm ở các phạm vi

1.4.3 Quy trình tiến hành phương pháp Delphi

Phần trước cung cấp một cái nhìn sơ bộ về phương pháp Delphi làm việcnhư thế nào, phần này sẽ đi vào chi tiết hơn về các hoạt động của phương phápDelphi Trước tiên, cần trả lời hai câu hỏi Đầu tiên là tại sao hỏi ý kiến của nhiềuchuyên gia thay vì chỉ duy nhất một chuyên gia Lý do là một cá nhân khi trả lời cóthể quên đi một điều gì đó hoặc sai khi xem xét một vấn đề Clayton nói rõ rằngbằng cách kết hợp ý kiến của một số lượng lớn các chuyên gia, việc xác định sự

Câu hỏi thứ hai nếu một nhóm là tốt hơn so với một cá nhân, tại sao không

để các chuyên gia trong một phòng với nhau để cho phép họ động não và rút ra một

sự đồng thuận? Nếu các chuyên gia ngồi trong cùng một phòng dễ có hiện tượngmột vài cá nhân chi phối, kiểm soát các cuộc thảo luận và có khả năng quyết định sựđồng thuận bất chấp sự phản đối ban đầu, các thành viên còn lại thì e dè hơn.Phương pháp Delphi với việc khảo sát ẩn danh có thể ngăn ngừa các vấn đề tronggiao tiếp mặt đối mặt như vậy Người tham gia có thể trả lời với những ý kiến thật

Bắt đầu

Xác định vấn đề

Xác định nhómchuyên gia

Thực hiện khảo sát

Phân tích kết quả

Không

Đạt được sựđồng thuận?

Có

Ý kiến tổng hợp

Kết quả cuối cùng

Hình 1-5: Quy trình tiến hành phương pháp Delphi

Đầu tiên là xác định vấn đề cần nghiên cứu Trong luận văn này, vấn đềnghiên cứu là xác định các yếu tố rủi ro ảnh hưởng đến thành công của dự án phầnmềm Bước tiếp theo là xây dựng bảng câu hỏi có các dữ liệu cần thiết để cácchuyên gia trả lời cho câu hỏi nghiên cứu Kế đến là xác định các chuyên gia sẽtham gia khảo sát

Các câu hỏi được sau đó được gửi đến các chuyên gia và các câu trả lời sẽđược thu thập, phân tích và tóm tắt Nếu không đạt được sự đồng thuận, các câu trảlời tóm tắt sau đó sẽ được gửi trở lại các chuyên gia để cho phép họ suy nghĩ lại về

những câu hỏi mà giờ đây họ có thêm các thông tin từ các thành viên khác trongnhóm Quá trình gửi các câu hỏi và sau đó nhận được câu trả lời và phân tích chúngtiếp tục theo mô hình vòng lặp Mỗi khi bảng câu hỏi mới được phân phối là đánhdấu sự khởi đầu của một vòng mới Số vòng được xác định bởi việc đạt được sựđồng thuận ý kiến của các chuyên gia Thời kỳ sơ khai của phương pháp Delphi, dothiếu công nghệ, bảng câu hỏi được gửi bằng phương pháp gửi thư truyền thống.Tùy thuộc vào số vòng cần thiết để đạt được sự đồng thuận, quá trình mất từ vàitháng đến một hoặc hai năm để hoàn thành Kỹ thuật ngày nay cho phép quá trìnhkhảo sát nhanh hơn, trong luận văn này, tất cả các thông tin liên lạc sẽ được thựchiện thông qua sự kết hợp giữa phỏng vấn trực tiếp, qua chat và qua e-mail.

1.4.4 Số vòng phỏng vấn trong phương pháp Delphi

Như đã đề cập ở phần trên, mỗi lần một bảng câu hỏi được phân phối chocác chuyên gia và trả lại cho người nghiên cứu tạo thành một vòng của phươngpháp Delphi Câu hỏi đặt ra là cần thiết phải thực hiện bao nhiêu vòng Delphi đểđảm bảo dữ liệu được ổn định Clayton nói rằng chỉ cần bốn vòng và là vòng cuốicùng được gửi ra để "cung cấp lý do tại sao họ đồng ý hay không đồng ý với kết

Trong nghiên cứu gần đây, Hasson và các đồng sự giới hạn số lượng các vòng tùy

thể của số vòng cần thiết Hầu hết các nhà nghiên cứu sử dụng phương pháp Delphidựa trên tiêu chuẩn là sự đồng thuận và thời gian cho phép Dựa trên các phân tíchtrên, phương pháp Delphi trong nghiên cứu này sẽ có tối thiểu là hai vòng và tối đa

là bốn vòng

1.4.5 Câu hỏi phỏng vấn trong phương pháp Delphi

Mitchell đi sâu vào nghiên cứu chi tiết việc xây dựng và quản lý các câu hỏiDelphi Ông cho rằng chiều dài bảng câu hỏi phụ thuộc vào việc phải mất bao lâu đểmỗi chuyên gia trả lời bảng câu hỏi Ông cho rằng, bảng câu hỏi không nên quá

mỗi vòng của phương pháp Delphi Theo ông, câu hỏi cần phải rõ ràng và khôngnên giống hệt nhau từ vòng này đến vòng khác bởi vì sự lặp lại có thể gây ra sự

cũng thảo luận về các câu hỏi theo từng vòng Ông nói rằng câu hỏi vòng 1 nênđược diễn đạt một cách rõ ràng nhưng cho phép sự tự do nhất trong trả lời (câu hỏimở) Sau khi các câu trả lời vòng một thu thập được, một báo cáo tóm tắt các ý kiếntrả lời được soạn và sau đó gửi lại cho các chuyên gia để bắt đầu vòng hai Trongvòng hai, bắt đầu quá trình tìm kiếm sự đồng thuận Để hỗ trợ trong việc tìm kiếm

sự đồng thuận, người khảo sát phải cung cấp lý do khi muốn thay đổi câu trả lờitrước đó của các chuyên gia Trong vòng 3 và vòng tiếp theo, các bảng hỏi nên tómtắt các câu trả lời với một bản tóm tắt lý do cho việc thay đổi các các câu trả lời và

trong nghiên cứu này sẽ được xây dựng theo các nghiên cứu của Clayton vàMitchell Số câu hỏi sẽ được giới hạn đến 10 hoặc ít hơn Thời gian cần thiết đểhoàn thành bảng câu hỏi được ước tính là 20 phút Bảng câu hỏi được thay đổitrong mỗi vòng dựa trên kết quả của vòng trước Điều này sẽ đảm bảo mỗi chuyêngia có cơ hội để đánh giá lại từng câu hỏi

1.4.6 Sự đồng thuận trong phương pháp Delphi

Các vòng Delphi cuối cùng phải kết thúc Như thiết lập trước khi bắt đầu,một khi đạt được sự đồng thuận, các vòng sẽ không còn tiếp tục Theo từ điểnWebster’s New International Unabridged định nghĩa sự đồng thuận là nhất trí hay

phương pháp Delphi trong nghiên cứu này, một khi các chuyên gia đạt đến ý kiến

đa số, quá trình này hoàn tất Vì vậy, trong điều khoản của các ứng dụng củaphương pháp Delphi cho nghiên cứu, đồng thuận được định nghĩa là tỷ lệ các ýkiến khác nhau giữa các vòng trước và vòng tiếp theo là ít hơn 10% Trong trườnghợp tỉ lệ ở vòng 4 là cao hơn 10% hoặc không có câu trả lời cho một yếu tố nào đótại vòng bất kỳ, nó sẽ không có sự đồng thuận và yếu tố này là không đáng kể chonghiên cứu và vòng tiếp theo, nó sẽ được bỏ ra khỏi câu hỏi

1.4.7 Các chuyên gia trong phương pháp Delphi

Một trở ngại khác khi thực hiện phương pháp Delphi là chọn bao nhiêuchuyên gia thì thích hợp Spinelli tiến hành nghiên cứu sử dụng phương phápDelphi và các chuyên gia bao gồm 24 thành viên chủ chốt có hiểu biết về các yếu tố

một cách tiếp cận khác để thiết lập nhóm chuyên gia Ludwig nói rằng "số người trảlời được xác định bằng số lượng người cần thiết để tạo thành một đại diện tổnghợp của các phán đoán và tóm tắt khả năng thông tin của nhóm nghiên cứu".Ludwig sau đó tuyên bố "Đa số các nghiên cứu Delphi đã sử dụng từ 15 đến 20

trong quá trình lựa chọn của họ "mười thành viên của nhóm trả lời đại diện cho một

phương pháp lựa chọn nhóm chuyên gia bằng cách "Đầu tiên, không có thoả thuậnliên quan đến kích thước của nhóm chuyên gia, cũng không có bất kỳ khuyến cáo

Nhóm chuyên gia được thiết lập để trả lời các câu hỏi nghiên cứu đặt ratrong luận văn này dựa vào số năm kinh nghiệm của các thành viên và đại diện cácthành phần tham gia dự án

Một khi kích thước của nhóm chuyên gia đã được quyết định, tiêu chuẩnxây dựng là cần thiết để đánh giá các chuyên gia Trong khi thảo luận về chủ đề lựachọn thành viên của nhóm chuyên gia, Mitchell phát biểu rằng "Không có báo cáo

trong ngiên cứu của họ, tóm tắt các tiêu chí để xác định các chuyên gia được sửdụng trong một số nghiên cứu Delphi trong lĩnh vực của họ Tựu chung là: kinhnghiệm chung trong bảy năm, kinh nghiệm cụ thể là năm năm, ít nhất một bài báođược công bố, ít nhất một lần trình bày tại hội nghị quốc gia và kinh nghiệm gần

Với nghiên cứu này, những tiêu chuẩn chung được yêu cầu: kinh nghiệmchung là năm năm; kinh nghiệm cụ thể là ba năm, kinh nghiệm gần đây trong vòngnăm năm qua, và không có các bài thuyết trình hoặc các ấn phẩm và chi tiết của các

có hơn 5 năm làm việc cho công ty phần mềm, và họ là những kỹ thuật viên phát

triển sản phẩm (developer), các nhà giám sát và quản lý kỹ thuật)

làm việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, và các nhà quản lý)

Tham khảo danh sách các chuyên gia ở phục lục 3

1.4.8 Sử dụng phương pháp Delphi

Phương pháp Delphi đã có nhiều công dụng trong nghiên cứu Theo cuốnsách về phương pháp Delphi: Kỹ thuật và Ứng dụng, phương pháp Delphi chủ yếuđược sử dụng như một công cụ dự báo vào đầu những năm 1960 và tiếp tục tớingày hôm nay Phương pháp Delphi được sử dụng để: dự báo quy phạm, xác địnhgiá trị; ước lượng chất lượng cuộc sống, mô phỏng và đưa ra quyết định thực tế vàlập kế hoạch Cuốn sách cũng chỉ ra rằng các phương pháp Delphi được sử dụngrộng rãi để " phán xét dữ liệu đầu vào " khi các dữ liệu khác là không có hoặc quá

kê việc sử dụng các phương pháp Delphi theo lĩnh vực nghiên cứu tổng cộng là 800nghiên cứu Delphi được sử dụng nhiều nhất trong khoa học vật lý và kỹ thuật (26%của tất cả các nghiên cứu được tiến hành) và đứng thứ hai là sử dụng trong kinh

1.4.9 Hạn chế của phương pháp Delphi

Mặc dù Delphi là một phương pháp dự báo có lịch sự phát triển lâu đời, được

áp dụng khá phổ biến và có độ tin cậy cao, nhưng nó vẫn tồn tại nhiều hạn chế đáng

kể Penelope (2003) cho rằng phương pháp Delphi thường bị chỉ trích ở những điểm