Kiểm thửphần mềm là một công việc đòi hỏi rất nhiều thời gian trong
qui trình phát triển phần mềm. Thế nhưng, kiểm thử phần mềm lại thường
được thực hiện vào pha gần cuối của vòng đời phát triển hệthống khi tiền bạc
và thời gian không còn dư rảnữa. Những người quản lý đều rất mong muốn
sớm có được một phiên bản của sản phẩm và thường thúc ép những người
kiểm thử phải hoàn thành công việc trong một khoảng thời gian không dễ
dàng có thểthực hiện được. Nhưng cho dù thếnào thì những người kiểm thử
vẫn phải làm công việc của họ, và vì vậy có thểhọkhông thểkiểm thửtất cả
những thứcần phải kiểm thử. Do đó, họchỉkiểm thửnhững thứmà họcho là
quan trọng nhất.
Mục tiêu của luận văn là nghiên cứu các cách tiếp cận kiểm thửkhác
nhau và tìm cách đềxuất một phương pháp kiểm thửhệthống dựa trên các rủi
ro đã phân tích được. Những rủi ro có thểcó đối với hệthống sẽđược phân
tích cho từng ca sửdụng. Việc đánh giá những rủi ro này sẽđược sửdụng để
tìm ra bản chất của rủi ro cho từng ca sửdụng. Các ca kiểm thửsẽ được thiết
lập từnhững ca sửdụng này và các ca kiểm thửcó rủi ro cao nhất sẽđược
chọn đểthực hiện. Ngoài ra, trong luận văn sẽxác định thêm những yêu cầu
cần thiết cho việc xây dựng một công cụphần mềm hỗtrợcho phương pháp
kiểm thửnày và đềxuất một mô hình thửnghiệm.
Kinh nghiệm cho thấy khi gặp một vấn đềnào đó trong cuộc sống, con
người thường giải quyết bằng cách nhớlại những vấn đềhọđã gặp trước đây
đểtìm ra vấn đềtương tự, rồi lục lại trí nhớđểtìm lại cách giải quyết của vấn
đềtương tựnày, và cuối cùng điều chỉnh cách giải quyết vừa tìm thấy nếu cần
thiết đểđưa ra cách giải quyết hợp lý cho vấn đềhiện tại của mình. Trong
phân tích và quản lý rủi ro cũng vậy, khi tiếp nhận một dựán, những người
5
quản trịdựán bao giờcũng nhớlại những dựán trong quá khứmà họđã quản
lý đểtìm ra một sốdựán tương tự, sau đó tìm lại danh sách rủi ro của các dự
án tương tựnày, và cuối cùng hiệu chỉnh trên các danh sách rủi ro vừa tìm
thấy cho phù hợp với ngữcảnh hiện tại đểđưa ra dựđoán danh sách rủi ro
cho dựán đang phát triển. Thực tế, các dựán luôn luôn có một độtương tự
nhất định tùy theo hướng nhìn nhận của người quản trịdựán và rủi ro phần
mềm là một vấn đềphức tạp không nằm trong tầm kiểm soát của người quản
trịdựán.
Mục tiêu của mô hình là đảm bảo tựđộng hóa một phần quá trình phân
tích và quản lý rủi ro. Dựa trên những thông tin vềphân tích và quản lý rủi ro
của các dựán phần mềm đã hoàn thành, mô hình đưa ra một dựđoán danh
sách rủi ro cho dựán hiện tại, và mỗi rủi ro trong danh sách này là một trong
những rủi ro đã được dựđoán trong quá khứ. Vì vậy khi sửdụng mô hình
này, các nhà quản trịdựán có thểtận dụng và trau dồi những kinh nghiệm
phân tích và quản lý rủi ro mà họ đã trải qua trong quá khứ, và họcó thểtựbổ
sung kinh nghiệm bằng cách thêm những rủi ro mới xuất hiện và kếhoạch
quản lý rủi ro tương ứng vào danh sách rủi ro của dựán hiện tại.
Ngoài ra, do đặc điểm của lý thuyết, mô hình thửnghiệm được đềxuất
trong luận văn chỉáp dụng trong một ngữcảnh hẹp, chẳng hạn một công ty
phần mềm. Hiện nay, các công ty phần mềm có xu hướng phát triển phần
mềm trong một sốlĩnh vực nhất định, đáp ứng nhu cầu của một sốđối tượng
khách hàng nhất định, sửdụng một sốcông nghệphát triển nhất định, nên
xây dựng mô hình trong một ngữcảnh hẹp là hoàn toàn hợp lý.
6
Cấu trúc luận văn
Luận văn gồm 4 chương, nội dung của mỗi chương được tóm tắt như sau:
Chương 1:Trình bày những khái niệm cơ bản vềkiểm thửnói chung và kiểm
thửdựa trên các rủi ro.
Chương 2:Trình bày các phương pháp phân loại ưu tiên các kiểm thửrủi ro
và so sánh các phương pháp kiểm thửdựa trên rủi ro.
Chương 3:Đềxuất một phương pháp kiểm thửdựa trên rủi ro mới.
Chương 4:Phân tích các yêu cầu của một công cụphần mềm kiểm thử và
thiết kếcác giao diện và cơ sởdữliệu của phần mềm kiểm thử.
71 trang |
Chia sẻ: oanhnt | Lượt xem: 1314 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Luận văn Phân tích các yêu cầu của một công cụphần mềm kiểm thử và thiết kếcác giao diện và cơ sởdữliệu của phần mềm kiểm thử, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
LỜI CẢM ƠN
Trước tiên, tôi muốn gửi lời cảm ơn đến thầy giáo TS. Bùi Thế Hồng,
người đã trực tiếp hướng dẫn tôi thực hiện luận văn này. Tôi cũng muốn bày
tỏ lòng biết ơn đến các thầy giáo Viện Công nghệ thông tin và Khoa Công
nghệ thông tin - Đại học Thái Nguyên đã tận tình dạy dỗ và tạo mọi điều
kiện học tập thuận lợi cho tôi trong suốt khoá học qua.
Tôi xin cảm ơn lãnh đạo Bệnh viện Y học cổ truyền Thái Nguyên, các
anh chị đồng nghiệp đã tạo điều kiện cho tôi tham gia và hoàn thành khoá
học. Tôi cũng xin cảm ơn các bạn của tôi, những người luôn bên cạnh động
viên, giúp đỡ, và đã đóng góp nhiều ý kiến thiết thực trong quá trình học tập
và thực hiện luận văn.
Cuối cùng, tôi muốn gửi lời cảm ơn đến gia đình, đặc biệt là bố mẹ,
chồng và con tôi - những người luôn hết mình yêu thương, dìu dắt và ủng hộ
tôi trong cuộc sống./.
Thái Nguyên, tháng 11 năm 2008
Sinh viên thực hiện
Trần Thị Ngọc Liên
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
MỤC LỤC
Danh sách bảng.................................................................................... 1
Danh sách hình vẽ ................................................................................ 2
Ký hiệu viết tắt ...................................................................................... 3
Lời nói đầu ............................................................................................ 4
Cấu trúc luận văn.................................................................................. 6
1.1 Rủi ro .................................................................................................. 7
1.1.1 Độ phơi nhiễm rủi ro ............................................................................ 8
1.1.2 Xử lý rủi ro ........................................................................................... 8
1.1.3 Quản lý rủi ro ....................................................................................... 9
1.1.4 Rủi ro trong công nghệ phần mềm .................................................... 10
1.2 Kiểm thử phần mềm ......................................................................... 12
1.2.1 Kiểm thử và các ca kiểm thử ............................................................. 12
1.2.2 Kiểm thử hộp đen và hộp trắng ......................................................... 13
1.2.3 Quá trình kiểm thử ............................................................................. 14
1.3 Kiểm thử dựa trên các rủi ro ............................................................ 16
1.3.1 Phân tích sơ bộ các mối nguy hiểm (PHA) ........................................ 17
1.3.2 Phân tích các kiểu lỗi và hậu quả (FMEA) ......................................... 17
1.3.3 Phân tích lỗi tiềm ẩn và khả năng thực hiện (HazOp) ....................... 18
1.3.4 Kiểm thử dựa trên rủi ro theo kinh nghiệm ........................................ 19
1.3.5 Ngăn ngừa các mối nguy hiểm .......................................................... 22
Tóm tắt Chương 1 .................................................................................. 24
Chương 2 Phân loại ưu tiên các kiểm thử .........................................26
2.1 Các nhân tố gây ra thiệt hại ............................................................. 26
2.2 Các hành động phát sinh sai sót trong quá trình phát triển ............. 28
2.3 Phát sinh lỗi trong khi lập trình ......................................................... 29
2.4 Kiểm thử hệ thống theo độ phơi nhiễm rủi ro ................................... 30
2.5 Lập thứ tự kiểm thử ưu tiên trước khi hết kỳ hạn ............................ 32
2.6 So sách các cách tiếp cận khác nhau .............................................. 33
Tóm tắt Chương 2 .................................................................................. 35
Chương 3 Một phương pháp kiểm thử mới .......................................36
3.1 Sắp thứ tự ưu tiên các rủi ro và tạo lập các kiểm thử và các rào cản
có liên quan ............................................................................................ 36
3.2 Sắp thứ tự ưu tiên kiểm thử cho các modules trong hệ thống ......... 40
3.3 Lập danh sách ưu tiên kiểm thử ....................................................... 44
Tóm tắt Chương 3 .................................................................................. 47
Chương 4. Đặc tả các yêu cầu cho công cụ kiểm thử .......................48
4.1 Các yêu cầu chức năng.................................................................... 48
4.1.1 Dự án................................................................................................. 48
4.1.2 Loại rủi ro ........................................................................................... 48
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
4.1.3 Module ............................................................................................... 49
4.1.4 Nguy cơ ............................................................................................. 50
4.1.5 Kiểm thử ............................................................................................ 50
4.1.6 Rào cản ............................................................................................. 51
4.2 Các yêu cầu không chức năng ......................................................... 51
4.2.1 Chất lượng ........................................................................................ 52
4.2.1 Công nghệ ......................................................................................... 52
4.3. Thiết kế công cụ phần mềm kiểm thử ............................................. 52
4.3.1 Ngôn ngữ thực hiện ........................................................................... 52
4.3.2 Mô hình dữ liệu .................................................................................. 53
4.4 Giao diện .......................................................................................... 55
4.4.2 Tạo ra một dự án mới ........................................................................ 57
4.4.3 Lựa chọn và trọng số các loại rủi ro .................................................. 58
4.4.4 Danh sách module ............................................................................. 59
4.4.5 Giá trị những module ......................................................................... 60
4.4.6 Tạo một kiểm thử mới ....................................................................... 61
4.4.7 Danh sách kiểm thử .......................................................................... 62
4.4.8 Danh sách những rủi ro ..................................................................... 63
4.4.9 Danh sách những rào cản ................................................................. 64
Tóm tắt chương 4 ................................................................................... 66
Kết luận ...............................................................................................67
Tài liệu tham khảo ..............................................................................68
1
Danh sách bảng
Tên bảng Trang
Bảng 1.1 Bảng PHA ………………………………………………….
Bảng 1.2 Cấu trúc của bảng FMEA ………………………………….
Bảng 1.3: Bảng HazOp ………………………………………………
Bảng 1.4: Danh sách rủi ro tổng quát ………………………………...
Bảng 1.5: Danh sách rủi ro cho việc cài đặt ………………………….
Bảng 1.6: Ma trận rủi ro của các thành phần …………………………
Bảng 2.1: Độ phơi nhiễm rủi ro đối với chức năng “Đóng tài khoản”
………………………………………………………………………..
Bảng 2.2: Ví dụ về tính toán rủi ro …………………………………..
Bảng 3.1: Các thông tin cần biết từ việc phân tích lỗi ……………….
Bảng 3.2: Ma trận rủi ro cho độ phơi nhiễm …………………………
Bảng 3.3: Bảng với các thông tin nhận được từ phân tích rủi ro …….
Bảng 3.4: Các nhóm rủi ro và các nhân tố rủi ro được sử dụng trong
phân tích rủi ro ………………………………………………………..
Bảng 3.5: Tính toán chi phí (bằng số) ……………………………….
Bảng 3.6: Tính các số xác suất ……………………………………...
Bảng 3.7: Quá trình tính các số chi phí và các số xác suất …………..
Bảng 3.8: Thiệt hại tiềm ẩn đã được tính toán ……………………….
Bảng 3.9: Ma trận rủi ro được sử dụng trong lập thứ tự ưu tiên cuối
cùng …………………………………………………………………..
Bảng 3.10: Danh sách các kiểm thử được phân loại ưu tiên ……….
17
18
18
20
20
22
32
33
36
38
39
40
42
43
43
34
45
46
2
Danh sách hình vẽ
Tên hình vẽ Trang
Hình 1.1 Vùng ALAPR………………………………………………. 23
Hình 4.1: Sơ đồ lớp UML thể hiện mô hình dữ liệu cho
công cụ phần mềm …………………………………………………… 54
Hình 4.2: Màn hình của trang Xuatphat.asp ………………………… 56
Hình 4.3: Màn hình trang ThemDuan.aspx………………………….. 57
Hình 4.4: Màn hình trang LoaiRuiro.aspx ……………………………. 58
Hình 4.5: Màn hình trang Modules.aspx ……………………………... 59
Hình 4.6: Màn hình trang GiatriModules.aspx………………………... 60
Hình 4.7: Màn hình trang Taokiemthu.aspx…………………………....61
Hình 4.8: Màn hình trang Trangchu.aspx ……………………………...62
Hình 4.9: Màn hình trang Ruiro.aspx ………………………………….63
Hình 4.10: Màn hình trang Raocan.aspx ……………………………… 64
3
Ký hiệu viết tắt
PM Phần mềm
KTPM Kiểm thử phần mềm
PTPM Phát triển phần mềm
PHA Phân tích lỗi sơ bộ
HazOp Phân tích lỗi và khả năng thực hiện
FMEA Phân tích các kiểu lỗi và hậu quả FMEA
4
Lời nói đầu
Kiểm thử phần mềm là một công việc đòi hỏi rất nhiều thời gian trong
qui trình phát triển phần mềm. Thế nhưng, kiểm thử phần mềm lại thường
được thực hiện vào pha gần cuối của vòng đời phát triển hệ thống khi tiền bạc
và thời gian không còn dư rả nữa. Những người quản lý đều rất mong muốn
sớm có được một phiên bản của sản phẩm và thường thúc ép những người
kiểm thử phải hoàn thành công việc trong một khoảng thời gian không dễ
dàng có thể thực hiện được. Nhưng cho dù thế nào thì những người kiểm thử
vẫn phải làm công việc của họ, và vì vậy có thể họ không thể kiểm thử tất cả
những thứ cần phải kiểm thử. Do đó, họ chỉ kiểm thử những thứ mà họ cho là
quan trọng nhất.
Mục tiêu của luận văn là nghiên cứu các cách tiếp cận kiểm thử khác
nhau và tìm cách đề xuất một phương pháp kiểm thử hệ thống dựa trên các rủi
ro đã phân tích được. Những rủi ro có thể có đối với hệ thống sẽ được phân
tích cho từng ca sử dụng. Việc đánh giá những rủi ro này sẽ được sử dụng để
tìm ra bản chất của rủi ro cho từng ca sử dụng. Các ca kiểm thử sẽ được thiết
lập từ những ca sử dụng này và các ca kiểm thử có rủi ro cao nhất sẽ được
chọn để thực hiện. Ngoài ra, trong luận văn sẽ xác định thêm những yêu cầu
cần thiết cho việc xây dựng một công cụ phần mềm hỗ trợ cho phương pháp
kiểm thử này và đề xuất một mô hình thử nghiệm.
Kinh nghiệm cho thấy khi gặp một vấn đề nào đó trong cuộc sống, con
người thường giải quyết bằng cách nhớ lại những vấn đề họ đã gặp trước đây
để tìm ra vấn đề tương tự, rồi lục lại trí nhớ để tìm lại cách giải quyết của vấn
đề tương tự này, và cuối cùng điều chỉnh cách giải quyết vừa tìm thấy nếu cần
thiết để đưa ra cách giải quyết hợp lý cho vấn đề hiện tại của mình. Trong
phân tích và quản lý rủi ro cũng vậy, khi tiếp nhận một dự án, những người
5
quản trị dự án bao giờ cũng nhớ lại những dự án trong quá khứ mà họ đã quản
lý để tìm ra một số dự án tương tự, sau đó tìm lại danh sách rủi ro của các dự
án tương tự này, và cuối cùng hiệu chỉnh trên các danh sách rủi ro vừa tìm
thấy cho phù hợp với ngữ cảnh hiện tại để đưa ra dự đoán danh sách rủi ro
cho dự án đang phát triển. Thực tế, các dự án luôn luôn có một độ tương tự
nhất định tùy theo hướng nhìn nhận của người quản trị dự án và rủi ro phần
mềm là một vấn đề phức tạp không nằm trong tầm kiểm soát của người quản
trị dự án.
Mục tiêu của mô hình là đảm bảo tự động hóa một phần quá trình phân
tích và quản lý rủi ro. Dựa trên những thông tin về phân tích và quản lý rủi ro
của các dự án phần mềm đã hoàn thành, mô hình đưa ra một dự đoán danh
sách rủi ro cho dự án hiện tại, và mỗi rủi ro trong danh sách này là một trong
những rủi ro đã được dự đoán trong quá khứ. Vì vậy khi sử dụng mô hình
này, các nhà quản trị dự án có thể tận dụng và trau dồi những kinh nghiệm
phân tích và quản lý rủi ro mà họ đã trải qua trong quá khứ, và họ có thể tự bổ
sung kinh nghiệm bằng cách thêm những rủi ro mới xuất hiện và kế hoạch
quản lý rủi ro tương ứng vào danh sách rủi ro của dự án hiện tại.
Ngoài ra, do đặc điểm của lý thuyết, mô hình thử nghiệm được đề xuất
trong luận văn chỉ áp dụng trong một ngữ cảnh hẹp, chẳng hạn một công ty
phần mềm. Hiện nay, các công ty phần mềm có xu hướng phát triển phần
mềm trong một số lĩnh vực nhất định, đáp ứng nhu cầu của một số đối tượng
khách hàng nhất định, sử dụng một số công nghệ phát triển nhất định, … nên
xây dựng mô hình trong một ngữ cảnh hẹp là hoàn toàn hợp lý.
6
Cấu trúc luận văn
Luận văn gồm 4 chương, nội dung của mỗi chương được tóm tắt như sau:
Chương 1: Trình bày những khái niệm cơ bản về kiểm thử nói chung và kiểm
thử dựa trên các rủi ro.
Chương 2: Trình bày các phương pháp phân loại ưu tiên các kiểm thử rủi ro
và so sánh các phương pháp kiểm thử dựa trên rủi ro.
Chương 3: Đề xuất một phương pháp kiểm thử dựa trên rủi ro mới.
Chương 4: Phân tích các yêu cầu của một công cụ phần mềm kiểm thử và
thiết kế các giao diện và cơ sở dữ liệu của phần mềm kiểm thử.
7
Chương 1 Kiểm thử phần mềm dựa trên các rủi ro
Việc xem xét các rủi ro trong kiểm thử phần mềm không phải là mới.
Những người kiểm thử phần mềm có kinh nghiệm thường kiểm thử hệ thống
dựa trên các rủi ro với những linh cảm riêng. Hiện tại, đã có một vài cách tiếp
cận dùng để kiểm thử phần mềm dựa trên các rủi ro.
Mục tiêu của chương này là tìm hiểu xem rủi ro trong công nghệ phần
mềm là gì và cách phòng ngừa, xử lý các rủi ro. Tiếp theo là nghiên cứu để
biết rõ được kiểm thử phần mềm là gì và có các loại hình kiểm thử nào. Cuối
cùng là nghiên cứu tìm hiểu một số phương pháp kiểm thử dựa trên các rủi ro
đã phát hiện được khi phân tích.
1.1 Rủi ro
Mỗi người đều có một ý niệm nào đó về rủi ro. Hàng ngày, chúng ta có
thể gặp phải các rủi ro nào đó. Để có được một cái gì đó người ta thường phải
chấp nhận các rủi ro. Băng qua một đường phố đông đúc để uống một tách cà
phê có thể sẽ bị một tai nạn giao thông là một ví dụ về việc chấp nhận rủi ro
để có một lợi ích nào đó. Việc mua xổ số là ví dụ khác của việc chấp nhận rủi
ro, ta có thể được hoặc có thể mất. Trong thực tế, một số người sẵn sàng chấp
nhận rủi ro trong khi những người khác lại rất ghét rủi ro. Theo từ điển
Wikipedia thì “Rủi ro là thiệt hại tiềm tàng mà có thể xuất hiện từ quá trình
hiện hữu nào đó hoặc từ sự kiện tương lai nào đó”. Tức là, rủi ro chưa trở
thành một vấn đề nhưng nó có thể là một vấn đề nếu không tiến hành những
hành động phù hợp. Trong ngữ cảnh một dự án, rủi ro là khả năng xảy ra một
sự kiện nào đó và khả năng ảnh hưởng đến những mục tiêu của dự án nếu sự
kiện đó xảy ra. Nó chứa đựng khả năng thiệt hại, và khả năng dẫn đến những
sai khác so với kết quả mong đợi.
8
Tóm lại, rủi ro gồm hai thành phần: khả năng xảy ra và hậu quả phải
gánh chịu nếu nó xảy ra. Hai thành phần này tạo nên hai đặc trưng của rủi ro:
không chắc chắn (rủi ro có thể xảy ra hoặc không) và gây thiệt hại (rủi ro
mang đến những hậu quả không mong đợi).
Như vậy, rủi ro là nhân tố bất kỳ có thể gây trở ngại cho thành công của
dự án. Một rủi ro chưa phải là một vấn đề mà chính xác hơn một rủi ro là một
vấn đề có thể xảy ra.
1.1.1 Độ phơi nhiễm rủi ro
Khi xem xét rủi ro, chúng ta phải tính đến những thiệt hại do rủi ro gây
ra và khả năng có thể xảy ra rủi ro này. Thiệt hại là những thứ không may bị
mất mát như thời gian, chất lượng, tiền bạc, kiểm soát hoặc hiểu biết.
Khả năng mà một sự kiện có thể dẫn đến các thiệt hại nào đó thường được
tính như một xác suất có giá trị từ 0 đến 1. Nếu xác suất này bằng 0 thì sự
kiện sẽ không bao giờ xảy ra và không được coi là một rủi ro. Một xác suất
bằng 1 có nghĩa là sự kiện này sẽ xảy ra trừ khi một vấn đề nào đó được giải
quyết hoặc thay đổi.
Nếu ta có một số rủi ro có thể xảy ra đối với một vấn đề nào đó thì có
thể sẽ rất khó để xác định xem những rủi ro nào cần phải đặc biệt chú ý. Bởi
vậy cần phải có một phương thức để đánh giá mức độ nguy hại của các rủi ro.
Một trong những cách thức đó là tính Độ phơi nhiễm rủi ro (Risk Exposure).
Đây là một tính toán đơn giản dùng để gán cho mỗi rủi ro một giá trị số cho
phép so sánh các rủi ro với nhau.
Độ phơi nhiễm rủi ro = Xác suất xảy ra rủi ro * Tổng thiệt hại nếu rủi ro xảy ra
1.1.2 Xử lý rủi ro
Sau khi nhận dạng được các rủi ro, chúng ta sẽ xem xét phải làm gì với
chúng. Trước hết, cần phải xem xét mức độ mà ta có thể thay đổi được các
9
hậu quả của rủi ro. Tức là chúng ta có thể giảm thiểu hoặc ngăn ngừa hậu quả
của một rủi ro ở mức độ như thế nào. Các rủi ro có thể được chấp nhận, bị
ngăn ngừa hoặc được san sẻ.
Nếu rủi ro được chấp nhận thì những thiệt hại do rủi ro này gây ra phải
được tính vào chi phí của dự án. Nếu phải chấp nhận nhiều rủi ro thì cần phải
sử dụng độ phơi nhiễm rủi ro khi dự toán chi phí. Cách tính này sẽ cho một
dự toán với mức thiệt hại trung bình do các rủi ro gây ra.
Ngăn ngừa là cách giảm thiểu thiệt hại hoặc xác suất. Có thể làm được
điều đó bằng cách thay đổi điều kiện sao cho sự kiện này sẽ không xảy ra.
Trong công nghệ phần mềm, có thể tiến hành nhiều kiểm thử hơn để giảm
thiểu rủi ro. Việc kiểm thử sẽ giảm bớt những gì còn chưa chắc, chưa rõ ràng
và có thể phát hiện ra các lỗi quan trọng có thể sửa được.
San sẻ thiệt hại có nghĩa là chia những thiệt hại này cho một số bên
khác nhau, ví dụ như khách hàng, nhà thầu phụ hoặc một hãng bảo hiểm. Tuy
nhiên, việc san sẻ thiệt hại cho khách hàng lại là một rủi ro vì nó sẽ làm giảm
uy tín và có thể dẫn đến mất khách hàng và thị phần.
1.1.3 Quản lý rủi ro
Hậu quả do rủi ro gây ra xuất hiện dưới nhiều hình thức khác nhau,
có thể là chất lượng của sản phẩm cuối không đáp ứng được yêu cầu của
khách hàng, chi phí dự án tăng lên, giao sản phẩm chậm hay không đạt được
những mục tiêu đã đặt ra của dự án; và trường hợp xấu nhất là phá hỏng
toàn bộ dự án. Mỗi thay đổi dù nhỏ hay lớn, như thay đổi yêu cầu khách
hàng, thay đổi công nghệ phát triển hay thay đổi cơ cấu đội phát triển, đều
ảnh hưởng đến tính chất kịp thời và thành công của dự án. Hơn nữa, làm phần
mềm là một cuộc chiến giữa nhà quản trị dự án với những lựa chọn khác
nhau, chẳng hạn như nên dùng phương pháp và công nghệ phát triển nào,
cần khoảng bao nhiêu người phát triển hay chất lượng phần mềm như thế nào
10
là đủ …; và mỗi lựa chọn này có lợi và hại khác nhau đối với dự án. Vì thế
nhà quản trị dự án phải cân nhắc giữa cái được và cái mất để đưa ra lựa chọn
thích hợp nhất về phương pháp, công cụ, cơ cấu đội phát triển và tiêu chí chất
lượng cho từng dự án. Quả thực, rủi ro là vấn đề luôn tiềm ẩn trong phát triển
phần mềm và lúc nào cũng nằm chờ sẵn cơ hội để xuất hiện; do đó, quản lý
rủi ro trở thành điều kiện cần để dẫn đến thành công của dự án.
Quản lý rủi ro là một chuỗi các hoạt động hay các bước giúp đội
phát triển hiểu và quản lý các rủi ro. Hoạt động này diễn ra liên tục xuyên
suốt quá trình phát triển phần mềm nhằm tìm kiếm các rủi ro có thể xảy ra,
xác định mức độ quan trọng của rủi ro để ưu tiên giải quyết và thực thi các
chiến lược đã đề ra để khắc phục hậu quả nếu rủi ro xảy ra.
Thực tế, tất cả những người liên quan đến quá trình làm phần mềm,
bao gồm: quản trị dự án, kỹ sư phần mềm và khách hàng đều phải tham gia
hoạt động quản lý rủi ro; trong đó, quản trị dự án có vai trò và trách nhiệm
cao nhất đối với hoạt động này. Kết quả của quản lý rủi ro là một danh sách
rủi ro hoàn toàn dựa tr