Bài giảng Quản trị dự án phần mềm - Bài 12: Quản lý rủi ro - Đào Kiến Quốc

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Bộ môn Công nghệ Phần mềm
BÀI GIẢNG
QUẢN TRỊ DỰ ÁN PHẦN MỀM
Giảng viên: ĐÀO KIẾN QUỐC
Mobile 098.91.93.980 
Email: dkquoc@vnu.edu.vn
BÀI 12. QUẢN LÝ RỦI RO 
NỘI DUNG 

ĐẶC ĐIỂM CỦA RỦI RO
 Xảy ra trong tương lai: có thể là hậu quả của những
việc làm bây giờ. Liệu có thể làm thay đổi tương lai
 Rủi ro liên quan tới sự thay đối, ví dụ như thay đổi
về cách nghĩ, về quan điểm, về hoạt động, hoặc về
vị trí
 Thứ ba, rui ro liên quan tới sự lựa chọn, và sự
không chắc chắn về thứ tự lựa chọn đó.
 Rủi ro gây ra tổn thất
RỦI RO TRONG PHÁT TRIỂN PHẦN MỀM
 Trong tương lai: đó là gì. Vấn đề nhận diện rủi ro
 Những thay đổi trong yêu cầu của khách hàng,
trong sự phát triển của công nghệ, những mục tiêu
của máy tính, và tất cả những thực thể khách liên
quan tới dự án sẽ ảnh hưởng tới tính đúng đắn và
sự thành công như thế nào?
 Cuối cùng, chúng ta phải nắm giữ được sự lựa
chọn - những phương thức và công cụ gì sẽ được
sử dụng, bao nhiêu người liên quan, đầu tư vào
chất lượng thế nào là đủ.
CẤC VẤN ĐỀ ĐẶT RA
 Nhận diện các rủi ro tiềm tàng
 Ai tham gia nhận diện và giải quyết
 Tầm quan trọng: được chuẩn bị. Phần mềm là một 
lĩnh vực khó. Nhiều thứ có thể sai, Đó là lý do mà 
phải chuẩn bị - việc hiểu rủi ro và làm những công 
việc ước lượng trước để tránh hay quản lý chúng –
là một thành phần cơ bản của hoạt động quản lý dự 
án phần mềm 
 Những bước nào sẽ phải làm việc để quản lý rủi ro
 Sản phẩm của người làm quản lý: RMMM (risk 
mitigation, monitoring & management)
 Cần đưa ra một chiến lược phòng, chống rủi ro tổng 
quát trong CNPM
BA LOẠI RỦI RO
 Rủi ro dự án là mối đe doạ cho kế hoạch dự án: Kế hoạch lịch 
trình sai sẽ làm tăng chi phí. Có thể sai trong dự tính ngân sách, 
kế hoạch, cá nhân(nhân viên, tổ chức), tài nguyên, khách hàng, 
và những yêu cầu và ảnh hưởng của chúng 
 Rủi ro kĩ thuật là mối đe doạ chất lượng và tính đúng đắn của 
phần mềm được sản xuất. Nếu một lỗi kĩ thuật trở thành hiện 
thực, sự cài đặt có thể trở lên khó khăn hoặc không thể. Rủi ro kĩ 
thuật được tìm ra trong thiết kế, cài đặt, giao diện, sự kiểm tra, và 
vấn đề bảo trì. Thêm vào đó, sự tối nghĩa, kĩ thuật không vững 
chắc, kĩ thuật lỗi thời, và công nghệ “giới hạn sự hướng dẫn” cũng 
là tác nhân của rủi ro. Rủi ro kĩ thuật xảy ra vì vấn đề khó giải 
quyết hơn chúng ta nghĩ nó sẽ xảy ra.
 Rủi ro nghiệp vụ là mối đe doạ khả năng tồn tại của phần mềm 
được xây dựng. Rủi ro nghiệp vụ thường gây nguy hiểm cho dự 
án hoặc sản phẩm. Dự tính có 5 loại rủi ro nghiệp vụcó thể là (1) 
rủi ro thị trường, (2) rủi ro chiến lược), (3) xây dựng một sản 
phẩm với nỗ lực để bán nhưng không hiểu phải bán như thế nào, 
(4) rủi ro quản lý), và (5) rủi ro ngân sách). 
NHẬN DIỆN RỦI RO
 Quy mô sản phẩm (product size)
 Ảnh hưởng của thị trường (Businees Impact)
 Đặc tính của khách hàng (Customer 
Characteristics)
 Xác định quy trình (Process Definition)
 Môi trường phát triển
 Công nghệ để xây dựng phần mềm
 Quy mô và kinh nghiệm của nhân viên
CHECK LIST: QUY MÔ SẢN PHẨM
- Nếu bạn không tấn công rủi ro, rủi ro sẽ tấn công bạn (Tom Gillb)
• Ước lượng qui mô của sản phẩm bằng LOC hay FP?
• Độ đáng tin cậy trong việc ước lượng qui mô sản phẩm?
• Ước lượng qui mô bằng số lượng chương trình, các tệp tin 
và các giao tác?
• Tỉ lệ sai lệch trong qui mô của sản phẩm từ trung bình cộng 
của những sản phẩm đi trước.
• Kích cỡ của cơ sở dữ liệu đã được tạo và được sử dụng 
của sản phẩm?
• Số lượng người sử dụng sản phẩm?
• Số lượng những thay đổi yêu cầu cho sản phẩm? Giới hạn 
trước? Giới hạn sau?
• Số lượng của những phần mềm được sử dụng lại?
CHECK LIST: RỦI RO THỊ TRƯỜNG
 Hậu quả của sản phẩm đối với thu nhập của tổ chức làm phần 
mềm?
 Tầm nhìn của những người lãnh đạo?
 Sự hợp lý của thời hạn phát hành sản phẩm?
 Số lượng khách hàng tiềm năng?
 Số lượng các hệ thống khác, các sản phẩm khác có thể tương 
tác với sản phẩm của mình?
 Sản phẩm có tinh vi quá đối với người sử dụng không?
 Số lượng và chất lượng của người làm sản phẩm?
 Những chi phí bị mất khi sản phẩm có nhiều khiếm khuyết?
 Những chi phí phải mất khi phát hành sản phẩm muộn?
CHECK LIST: Rủi ro khách hàng
 Bạn đã làm việc với khách hàng nào trong quá khứ?
 Khách hàng có đưa ra ý kiến phức tạp với những gì được yêu 
cầu? Họ có đầu tư thời gian để viết nó không?
 Khách hàng sẽ đồng ý với việc sử dụng thời gian trong những 
yêu cầu hình thức trong những lần gặp gỡ để xác định qui mô 
dự án không?
 Khách hàng có sẵn sàng thiết lập mối liên hệ thường xuyên với 
nhà phát triển không?
 Khách hàng có sẵn sàng tham gia vào việc đánh giá không?
 Khách hàng có yêu cầu những kỹ thuật phức tạp trong sản phẩm 
không?
 Khách hàng có sẵn sàng để cho người phát triển dự án làm 
những công việc của họ không- như là sẽ không tham gia vào 
những công việc chi tiết kỹ thuật trong suốt quá trình dự án?
 Khách hàng có hiểu về tiến trình phần mềm hay không?
 Mỗi câu trả lời không đều có nghĩa là có một rủi ro
CHECK LIST: RỦI RO QUY TRÌNH
 Có sử dụng các phương pháp để phân tích yêu cấu phần mềm 
không?
 Có sử dụng những công cụ để thiết kế kiến trúc và thiết kế dữ liệu 
hay không 
 Có sử dụng ngôn ngữ bậc cao (trên 90% m ã l ệnh) 
 Có sử dụng công cụ quản lý cấu hình 
 Có sử dụng công cụ hỗ trợ cho việc lập kế hoạch và theo dõi các 
hoạt động?
 Có đo chất lượng của tất cả các dự án phần mềm hay không?
 Có những công cụ phần mềm được sử dụng để hỗ trợ tiến trình 
phân tích và thiết kế phần mềm?
 Có những công cụ sử dụng để tạo ra những mẫu phần mềm?
 Có những công cụ phần mềm sử dụng để hỗ trợ cho việc kiểm 
thử không?
 Có những công cụ sử dụng để hỗ trợ các sản phẩm và quản lý tài 
liệu không?
 Mỗi câu trả lời không là một rủi ro
CHECK LIST: RỦI RO KỸ THUẬT
 Công nghệ xây dựng có mới đối với tổ chức của bạn không?
 Các nhu cầu của khách hàng có đòi hỏi sự sáng tạo của các thuật toán mới hay công 
nghệ vào/ ra không?
 Giao diện phần mềm với phần cứng có mới hay chưa qua thử thách không?
 Phần mềm để xây dựng giao diện với đại lý cung cấp các sản phẩm phần mềm đã 
qua thử thách?
 Phần mềm xây dựng giao diện với một hệ cơ sở dữ liệu đã được thử thách trong lĩnh 
vực ứng dụng này chưa?
 Giao diện người dùng chuyên biệt có đuợc yêu cầu không?
 Các yêu cầu về sản phẩm có đòi hỏi các thành phần chương trình không giống với 
bất kỳ thành phần nào đã được tổ chức bạn phát triển trước đó không?
 Các yêu cầu có đòi hỏi sử dụng phương pháp phân tích, thiết kế và kiểm thử mới 
không?
 Có yêu cầu sử dụng các PP phát triển phần mềm khác bình thường không?
 Có yêu cầu quá mức về việc đặt các ràng buộc thực thi lên sản phẩm không?
 Khách hàng có chắc chắn rằng chức năng yêu cầu là “có thể làm được” không?
 Mỗi câu trả lời không, vấn để tương ứng sẽ là một rủi ro
CHECK LIST: RỦI RO VỀ MÔI TRƯỜNG PHAT 
TRIỂN
 Có công cụ quản lý dự án phần mềm hay không?
 Có công cụ quản lý tiến trình phần mềm không?
 Có công cụ phân tích và thiết kế không?
 Các công cụ phân tích và thiết kế có cung cấp các phương pháp thích 
hợp cho sản phẩm được tạo ra không?
 Có các trình biên dịch hay thiết bị sinh mã thích hợp với sản phẩm cần 
xây dựng không?
 Có các công cụ kiểm thử và thích hợp với sản phẩm cần xây dựng hay 
không?
 Có các công cụ quản lý cấu hình phần mềm không?
 Môi trường có tận dụng cơ sở dữ liệu hay kho lưu trữ dữ liệu không?
 Tất cả các công cụ phần mềm có tích hợp với nhau không?
 Các thành viên của đội dự án đã được đào tạo về từng công cụ chưa?
 Có các chuyên gia nội bộ để trả lời các câu hỏi về các công cụ không?
 Trợ giúp và tài liệu trực tuyến cho các công cụ có đầy đủ không?
 Nếu phần lớn các câu hỏi trên được trả lời là “không”, môi trường phát 
triển phần mềm yếu và rủi ro cao.
CHECK LIST: RỦI RO VỀ NHÂN SỰ
 Có những người tốt nhất không?
 Những người này có phối hợp tốt các kỹ năng không?
 Có đủ người không?
 Nhân viên có tận tâm trong suốt thời gian dự án không?
 Có nhân viên nào chỉ làm việc bán thời gian cho dự án không?
 Nhân viên có mong chờ đúng mức về công việc sắp tới không?
 Nhân viên đã nhận được sự đào tạo cần thiết chưa?
 Sự thay thế công nhân giữa các nhân viên có đủ ít để cho phép 
tính liên tục không?
 Nếu câu trả lời cho bất kỳ câu hỏi nào là “không”, việc nghiên 
cứu thêm phải được đảm bảo để đánh giá khả năng rủi ro.
CÁC YẾU TỐ RỦI RO 
(PHƯƠNG PHÁP CỦA KHÔNG QUÂN MỸ)
 rủi ro hiệu quả - mức độ không chắc chắn trong 
việc đáp ứng các yêu cầu và thích hợp với dự định 
sử dụng của sản phẩm.
 rủi ro chi phí - mức độ không chắc chắn về ngân 
sách dự án.
 rủi ro hỗ trợ - mức độ không chắc chắn cho tính dễ 
dàng sửa chữa, thích nghi, và nâng cấp của phần 
mềm.
 rủi ro lịch trình - mức độ không chắc chắn về lịch 
biểu dự án và về việc sản phẩm sẽ được giao đúng 
hạn.
DỰ PHÒNG (ƯỚC TÍNH) RỦI RO
 (1) Xác xuất xảy ra nhận thấy được của một 
rủi ro; 
 (2) Mô tả các hậu quả của rủi ro; 
 (3) Ước lượng ảnh hưởng cua rủi ro lên dự 
án và sản phẩm; và 
 (4) Độ chính xác của thông tin về rủi ro 
BẢNG DỮ LIỆU RỦI RO
Loại Hiệu quả Hỗ trợ Chi phí Kế hoạch
Thảm 
hoạ
1
2
Nghiêm 
trọng
1
2
Bình 
thường
1
2
Không 
tránh 
được
1
2
1. Hậu quả tiềm ẩn chưa phát hiện được của lỗi
2. Hậu quả tiềm ẩn nếu như kết quả mong muốn 
không thể thực hiện được
BẢNG DỮ LIỆU RỦI RO
Rủi ro Loại Xác 
xuất
Ảnh 
hưởng
RMMM
1. Ước lượng sai có thể chậm đáng kể
2. Số người dùng lớn hơn kế hoạch
3. Khả năng dùng lại ít hơn kế hoạch
4. Người dùng phản đối dùng hệ thống
5. Phân phát giới hạn chặt chẽ hơn
6. Nguồn dự trữ bị mất
7. Khách hàng thay đổi yêu cầu
8. Công nghệ không như mong đợi
9. Thiếu hướng dẫn trong công cụ
10. Người quản lý thiếu kinh nghiệm
11. Khả năng thay đổi người quản lý 
PS
PS
PS
BU
BU
CU
PS
TE
DE
ST
ST 
60%
30%
70%
40%
50%
40%
80%
30%
80%
30%
60% 
2
3
2
3
2
1
2
1
3
2
2 
RMMM: Risk mitigation, monitoring, management
KÊ HOẠCH RMMM
 VÍ dụ: nhân viên bỏ việc
 Mitigation: chế độ lương bổng, sử dụng đúng 
chỗ
 Monitoring: thường xuyên theo dõi, nắm bắt 
được thông tin ảnh hưởng tới lòng trung 
thành của nhân viên
 Management:Phương án dự phòng, ký kết 
hợp đồng chặt chẽ, quản lý mã nguồn, lập 
trình đôi...
KÊ HOẠCH RMMM
 Một kế hoạch hiệu quả phải bao gồm
 Tránh được rủi ro
 Theo dõi được sự phát sinh về rủi ro
 Quản lý được rủi ro và lập kế hoạch động để 
đối phó
CẤU TRÚC CỦA TÀI LIỆU RMMM 
 I. Giới thiệu
– Phạm vi và mục đích của tài liệu
– Tổng quan về các rủi ro chính
– Trách nhiệm
 Quản lý
 Nhân viên kĩ thuật
 II. Bảng rủi ro dự án
– Miêu tả toàn bộ rủi ro phía trên đường giới hạn
– Yếu tố ảnh hưởng tới khả năng xảy ra.
CẤU TRÚC CỦA TÀI LIỆU RMMM 
 III. Hạn chế, giám sát và quản lý rủi ro
– n , Rủi ro thứ n 
 a. Giảm nhẹ hậu quá 
– Chiến lược chung
– Các bước cụ thể để hạn chế rủi ro
 b. Giám sát
– Yếu tố được giám sát
– Quan điểm giám sát
 c. Quản lý
– Kế hoạch cho việc phát sinh
– Xem xét đặc biệt
 Lập lịch kế hoạch RMMM
 Kết luận
HỎI VÀ ĐÁP
HẾT BÀI 12