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

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC KINH TẾ Tp.HỒ CHÍ MINH 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 TN

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC KINH TẾ Tp.HỒ CHÍ MINH

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: Q uản Trị Kinh Doanh

Mã Số : 60340102

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

i

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

ii

LỜI CẢM ƠN

Sau 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

iii

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

iv

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

v

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

vi

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 1 Bả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 2 Bả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à 1 Bả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 3 Bả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, 2 Bả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 4 Bả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 Bảng 3-8: Tóm tắt tỉ lệ khác biệt các yếu tố của nhóm các thành phần hữu quangiữa 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 1 Bả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 2 Bả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à 1 Bả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 3 Bả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 2 Bả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 4 Bả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 3 Bả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ữa cá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 1 Bả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 2 Bả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à 1 Bả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 3 Bả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à 2 Bả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 4 Bả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

vii

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 1 Bả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 3 Bả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 2 Bả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 4 Bả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 3 Bả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òng Bảng 3-33: Tóm tắt các yếu tố rủi ro đƣợc xác định

ix

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

Cụm từ

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

SDLC Software Development Life Cycle Vòng đời của dự án phát triển phần mềm

1

MỞ ĐẦU

Công nghệ thông tin đóng vai trò quan trọng trong cuộc sống của chúng ta ngà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 đất nướ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ại mộ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ậy ké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í 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, một con số khá lớn [49] Theo Boehm[7], 15-35% các dự án phần mềm bị hủy bỏ, trong 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á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ân phầ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ươ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 đó Dự án phần mềm nói chung là phức tạp và việc phát triển của dự án diễn ra trong một môi trường năng động, điều kiện kinh doanh và công nghệ thay đổi trong quá trình thực hiện dự án Người sử dụng thường không chắc chắn về nhu cầu của họ và thường xuyên thay đổi yêu cầu khi dự án đang thực hiệ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à không thỏa mãn người dùng [28]

Đã 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 phần mềm Mc Farlan [34], Brooks [9], Boehm [8] đã xác định được một số rủi ro 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ết quả thành công của dự án, dẫn đến sự chậm trễ và thất bại của dự án

2

Ở Việt Nam, các nghiên cứu về rủi ro trong dự án phần mềm chưa được 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 đượ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

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

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

- Những yếu tố rủi ro nào ả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 KMS Technology Việt Nam

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:

- 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ạ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

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ần mềm đã hoàn thành năm 2011 và quý I, II năm 2012 tại công ty KMS Technology Việ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

Phương pháp nghiên cứu định tính được dùng trong luận văn Dữ liệu thu thậ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

3

Đề 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ách thứ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ông củ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:

- Chương mở đầu: trình bày tóm lược lý do, mục tiêu, ý nghĩa, phạm vi, 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

- Chương 1: trình bày các lý thuyết về rủi ro, các yếu tố rủi ro trong dự á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

- Chương 2: giới thiệu về công ty KMS Technology và các dự án đã hoàn thành trong năm 2011 và quý I, II năm 2012

- Chương 3: trình bày kết quả của nghiên cứu sau quá trình xử lý dữ liệu

- Chương kết luận: đưa ra các kết luận, và kiến nghị của nghiên cứu

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, một con số khá lớn Theo Boehm [7], 15-35% các dự án phần mềm bị hủy bỏ, trong 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ác mụ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 độ,

độ tin cậy kém và không thỏa mãn người dùng [28] Hơn nữa rất khó để dự đ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ào thị 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ượt chi 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 lập trình và quản lý, điều này dẫn đến hiểu lầm và thiếu tin tưởng [28] Rõ ràng, sự 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ên quan là quan trọng hàng đầu trong việc phát triển dự án phần mềm, đặc biệt là trong cá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 đầu củ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 như hình dưới [32]

5

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 gian, nguồn lực và ngân sách [2]. Theo Turner va Muller [52], dự án là nỗ lực tạm 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ác yê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à chi phí để đạ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ác thô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 định tại một chi phí nhất định [1] Đối tượng liên quan chính của một dự án phần 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ủa mì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 tham gia thực hiện dự án, người xây dựng hệ thống phần mềm

6

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 trong ngâ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 các thành phần hữu quan (stakeholders’ satisfaction) [55]

Đá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 khác nhau tương ứng với vai trò của các bên trong dự án [4] Trong đề tài này, đá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ự án phầ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ần mề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ông tin 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 trong quá 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

7

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ẩm phầ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 thiết cho sự phát triển của sản phẩm [45]

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ạn nà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ệc phá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ần mề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 trong giai đoạn này [45]

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ẽ được phá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ạn phá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 tiếp theo là giai đoạn phát triển và kiểm thử trong SDLC [45]

G iai đ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 chuyển đổi thành các file thực thi trong giai đoạn này [45]

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ác nhau như kiểm tra hồi quy, kiểm tra hiệu suất … Dựa trên nhu cầu, các phương phá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ập trì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 Quá trình này tiếp tục cho đến khi hệ thống không còn thấy lỗi [45]

8

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

giai đoạn này, tài liệu thiết kế cho bảo trì và nâng cấp được thực hiện [45]

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

có Tất cả điều này được thực hiện trong giai đoạn hỗ trợ và bảo trì của SDLC [45]

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ận

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

- Rủi ro là sự ngẫu nhiên gây ảnh hưởng nghiêm trọng đến thành công của

dự án phần mềm[25].

- Rủi ro là một phần của công việc phát triển, quy trình, môi trường mà nếu

bỏ qua, sẽ làm tăng khả năng thất bại của dự án phần mềm[38].

- Rủi ro là bất trắc không lường trước liên quan đến sự thay đổi và bổ sung các yêu cầu kỹ thuật trong giai đoạn phát triển phần mềm[17].

- Rủi ro là tập hợp các yếu tố, điều kiện gây ảnh hưởng nghiêm trọng đến

thành công của dự án phần mềm [54] Trong luận văn này rủi ro được giải thích theo định nghĩa này

9

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ông của dự án phần mềm

- Boehm [8] bằng kinh nghiệm và qua bảng khảo sát các nhà quản lý dự án

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ếu cô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ất làm việc kém, (10) căng thẳng trong công việc

- Field [15] và Reel [40] liệt kê những rủi ro cần tránh để thực hiện một dự

á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ông thự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ó kinh nghiệm, nhà quản lý không chịu rút kinh nghiệm từ những sai lầm

- Keil và các cộng sự [25] sử dụng kỹ thuật Delphi với sự tham gia của các 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:

 Thiếu cam kết của quản lý cấp cao cho dự án, thiếu sự tham gia của 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

 Hiểu sai yêu cầu của khách hàng, quản lý sự thay đổi yêu cầu kém gây ảnh hưởng đến chi phí và lịch trình dự án

 Quản lý kém mong đợi của người sử dụng cuối cùng, nhân viên thiếu

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

 Thay đổi phạm vi hay mục tiêu và xung đột trong nội bộ khách hàng

10

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

- Schmidt và các cộng sự [44] liệt kê các yếu tố rủi ro ảnh hưởng đế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à:

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

 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

- Jiang và các cộng sự [23] đã sử dụng công cụ phần mềm đo lường rủi ro 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 triển bởi Barki và các cộng sự [6] và đã chỉ ra rằng: quy mô dự án, ứng dụng phức tạp, 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ác bê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ách hà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

- Iacovou và các cộng sự [22] xác định các yếu tố rủi ro quan trọng trong dự

á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ốn của người dùng, nhân viên thiếu kỹ năng và kiến thức cần thiết

11

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 danh sá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ác nhau 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ỉ ảnh hưởng đến các dự án cụ thể trong điều kiện cụ thể Tuy nhiên, một số yếu tố được bá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ể được kiểm soát bởi người quản lý dự án

Năm 2008, Sharma và các cộng sự [45] đưa ra một danh sách đầy đủ và toà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ữu quan, 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

Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp hay trong nội bộ khách hàng

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ết ban đầ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ành công Danh sách các rủi ro thuộc thể nhóm này là:

15

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ý doanh nghiệ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ỏ người quản lý dự án Keil và các cộng sự [25] nhận thấy rằng thiếu cam kết của 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ấp cao 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ự

án [3]

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ủa nhiề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ệc giả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, mất thời gian [47][59]

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 cộng sự [25] Nếu khách hàng không tham gia vào dự án, có một nguy cơ là 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ục tiê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àng trong 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ầu phầ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

16

đồ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à thầu [24]

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ủa sả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 ro khô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ây dự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ộc nhó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ầu hoặ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ữa cá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 yêu cầu, trao đổi thông tin và thay đổi yêu cầu tiếp theo [22].

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

Boehm [8] chỉ ra rằng các bên liên quan khác nhau trong một dự án phát 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ủa cá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ới ngườ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ết quả 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

17

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ính hữ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ăng củ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ử dụng sẽ dẫn đến thay đổi các yêu cầu của dự án Các nhà nghiên cứu [7][25] đề 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óng ngà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ột thiế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ác thô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ản phẩ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ác doanh nghiệp thiếu một sự hiểu biết đầy đủ về các phần mềm trong quy trình kinh doanh của họ Điều này bao gồm quản lý sự thay đổi trong quá trình phát triển phầ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ồm quản lý cả những thay đổi riêng lẻ và những thay đổi phụ thuộc Các nhà nghiên cứu cho rằng việc quản lý thay đổi không đúng cách là một trong những nguyên nhân hàng đầu dẫn đến sự thất bại của dự án phần mềm [19][39].

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 trong ngâ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

18

khó khăn trong việc lập lịch cho dự án Ropponen và Lyytinen [41] cho rằng rủi ro trong lập kế hoạch và thời gian sẽ được cải thiện với quản lý dự án có kinh nghiệ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ên chị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ăng tạ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 chi tiế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 đến khả 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

là một trong mười rủi ro hàng đầu ảnh hưởng đến các dự án phần

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

Theo Keil và các đồng sự [25], các vấn đề liên quan tới kỳ vọng của người

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ều này xảy ra do lập kế hoạch không đầy đủ và không thu thập thông tin từ khách hà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àm việ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 đến việc người dùng không hài lòng và tốn các chi phí không cần thiết [8]

19

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ân sách , hoặc thời gian, hoặc cả hai không đầy đủ, gây thất bại cho dự án Ước lượ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ể trong quá 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 kinh nghiệ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 đến tai 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 lượng không chính xác khác [16][44].

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ừa phả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 đe dọ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ệc quả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ạn hay 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úp xá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ự án giú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 như là một trong mười rủi ro hàng đầu ảnh hưởng đến các dự án phần mềm [47]

20

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ông nhấ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ợp vớ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àng tố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ài liệ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ầu thay đổ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 những quan hệ giao tiếp thích hợp là rất quan trọng [46]

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

là khách hàng phải thông tin đến tất cả các trưởng nhóm do đó trì hoãn dự án [51]

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

21 nguyên nhân chính của sự chậm trễ và thất bại của các dự án phần mềm [25][34]

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ân viê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 lực

và hiệu suất kém [42]

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ất lớn, vì cực kỳ khó khăn để có thể tìm được người có đầy đủ kinh nghiệm kỹ thuật trong một thời gian ngắn và hơn nữa, phải mất thời gian cho họ để thích nghi trong mộ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ự

án phát triển phần mềm [59]

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, thiếu sự cân bằng hoặc nhóm đa dạng, và không đầy đủ thông tin liên lạc [14].

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ình hoạ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ệu suấ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ềm khó đạ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à ngân sách sẽ làm hạn chế các nỗ lực cải thiện độ tin cậy phần mềm [59]

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ỳ

22

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ực hiệ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ó thể trì hoãn việc triển khai, do đó ảnh hưởng đến tiến độ tổng thể của dự án [37]

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át nhữ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ọa nghiê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 ro thuộ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ầu khô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ự án dẫn đến tăng chi phí và thời gian [27].

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ững thá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ây dự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ẻ hơn, tích cực triển khai các sản phẩm trong cùng một thị trường [5]

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 quan trọng Các nghiên cứu đã tìm ra rằng đôi khi do những thay đổi trong môi trường cạ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

23

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ấm dứ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 trở nên thờ ơ với sản phẩm [3].

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 quan trọng nhất Thứ nhất vì nó không thể kiểm soát được và thứ hai nó có thể gây ra thiệ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 50 của thế kỷ trước, tại tổ chức RAND Corporation, là kết quả của công trình nghiên cứ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 chúng[11]

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ác chuyên gia (Hwang và các đồng sự, 2006), đặc biệt với các kiến thức và chuyên ngành khác nhau Để giải quyết vấn đề này, phương pháp Delphi là một phương phá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ững thờ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

24

đã đượ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âu hỏ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áp nghiê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óp phần trong việc ra quyết định và để đạt được sự nhất trí theo nhóm ở các phạm vi khác nhau (Cochran, 1983 and Uhl, 1983) [10]

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ệc như 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áp Delphi 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ều chuyê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ằng bằ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ự thật sẽ chính xác hơn [11].

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ượng mộ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 đề trong giao 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 lòng hơn [11][29]

25

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ần mề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ác chuyê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ề

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

Bắt đầu

Xác định vấn đề

Xác định nhóm chuyên gia

Kết quả cuối cùng

Phân tích kết quả

Ý kiến tổng hợp

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

Có Không

26

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 trong nhó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úng tiế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à đánh dấ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, do thiế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ài tháng đến một hoặc hai năm để hoàn thành Kỹ thuật ngày nay cho phép quá trình khả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ực hiệ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 cho cá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ương phá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ối cùng được gửi ra để "cung cấp lý do tại sao họ đồng ý hay không đồng ý với kết quả cuối cùng" [11] Chan và các đồng sự thì thống nhất trong nghiên cứu của họ bằng cách thiết lập bốn vòng [10] Tuy nhiên, Ludwig cho rằng “Vòng Delphi tiếp tục cho đến khi đạt được sự đồng thuận hoặc không còn thông tin mới" [31] Trong khi một nghiên cứu tại Scotland, bởi Tiến sĩ Kerr, giới hạn số vòng là ba [26] 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 thuộc vào "thời gian cho phép" [20] Các nghiên cứu đã không tìm thấy một số cụ 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 Delphi dự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ích trê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ỏi Delphi Ô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á

27

30 phút để trả lời [36] Mitchell cũng thảo luận về việc xây dựng các câu hỏi cho 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ông nê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ự nhàm chán cho người tham gia, điều này gây cản trở kết quả khảo sát [36] Clayton 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ỏi mở) 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ến trả lời được soạn và sau đó gửi lại cho các chuyên gia để bắt đầu vòng hai Trong vò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ời trướ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óm tắ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à quá trình này tiếp tục cho đến khi sự đồng thuận được đáp ứng [36] Các câu hỏi 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 đổi trong 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ên gia 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ển Webster’s New International Unabridged định nghĩa sự đồng thuận là nhất trí hay thỏa thuận chung trong các quan điểm [57] Nếu định nghĩa được áp dụng cho 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ủa phươ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ường hợ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ể cho nghiên cứu và vòng tiếp theo, nó sẽ được bỏ ra khỏi câu hỏi

28

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êu chuyên gia thì thích hợp Spinelli tiến hành nghiên cứu sử dụng phương pháp Delphi 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ố

ảnh hưởng đến môi trường chung " [48] Ludwig tiến hành nghiên cứu, nhưng có 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ổng hợ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 người trả lời

và chạy trong thời gian vài tuần" [31] Chan và các cộng sự đã nêu 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ân phối rộng rãi của những chuyên gia " [10] Một nghiên cứu của Des Marchais giảm kích cỡ của nhóm chuyên gia đến sáu [13] William và Webb tóm tắ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ận liê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 nào liên quan đến kỹ thuật lấy mẫu" [58].

Nhóm chuyên gia được thiết lập để trả lời các câu hỏi nghiên cứu đặt ra trong 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ác thà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ẩn xây dựng là cần thiết để đánh giá các chuyên gia Trong khi thảo luận về chủ đề lựa chọ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 nào trong nghiên cứu Delphi về vấn đề lựa chọn này" [36]. Dawson và Brucker, 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à: kinh nghiệ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

đây trong vòng ba năm qua [12].

Với nghiên cứu này, những tiêu chuẩn chung được yêu cầu: kinh nghiệm chung là năm năm; kinh nghiệm cụ thể là ba năm, kinh nghiệm gần đây trong vòng nă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

• Nhóm 2: 10 người chủ chốt của bộ phận phát triển sản phẩm (những người

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)

• Nhóm 3: 10 người quan trọng của QA và BA (những người có hơn 5 năm 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ốn sá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ới ngày hôm nay Phương pháp Delphi được sử dụng để: dự báo quy phạm, xác định giá 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ụng rộ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á tốn

xuyên trong y tế và khoa học xã hội [20].Mitchell trích dẫn một bảng liệt 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à 800 nghiê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 doanh và kinh tế (23%) [36].

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