Quản Lý Rủi Ro Phần Mềm - Software Risk Management

1. CHƯƠNG 8:
SOFTWARE RISK MANAGEMENT
QUẢN LÝ RỦI RO PHẦN MỀM
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 1

2. Nội dung
• Hazard analysis (HA)
• Threat modeling ™
• Risk management
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 2

3. CƠSỞ CỦA QUẢN LÝ RỦI RO PHẦN MỀM
(FUNDAMENTALS OF SOFTWARE RISK MANAGEMENT)
• Dự án phải đối mặt với nhiều loại rủi ro gồm:
• Các rủi ro liên quan đến phạm vi dự án.
• Phải phụ thuộc vào một đối tác bên ngoài.
• Phải đối mặt với các rủi ro nảy sinh từ sự kém chính xác
của các ước lượng trước khi tiến hành dự án.
• Các rủi ro liên quan đến công nghệ
• Sự thiếu hiểu biết về các nguồn rủi ro cũng là nguồn gốc
của rủi ro…
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 3

4. CÁC YẾU TỐ CỦA QUẢN LÝ RỦI RO
(ELEMENTS OF RISK MANAGEMENT)
• Quản lý rủi ro là ứng dụng các công cụ và thủ tục thích
hợp để kiềm chế rủi ro dự án trong một giới hạn có thể
chấp nhận.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 4

5. CÁC YẾU TỐ CỦA QUẢN LÝ RỦI RO
(ELEMENTS OF RISK MANAGEMENT)
• Quản lý rủi ro bao gồm các hoạt động sau:
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 5

6. Đánh giá rủi ro (risk assessment) tr
93
• Đánh giá rủi ro (risk assessment) là quy trình khảo sát,
xác định và kiểm soát rủi ro trước khi chúng gây tổn thất
cho dự án.
• Nếu có 1 gì đó không hay đã xảy ra, nó là 1 vấn đề
(issue), không phải là rủi ro.
• Việc xử lý các vấn đề (problems and issues) phải theo qui
trình theo dõi trạng thái dự án và qui trình sửa lỗi, không
thuộc về quản lý rủi ro.
• Đánh giá rủi ro gồm:
• Định danh rủi ro (risk identification)
• Phân tích rủi ro (risk analysis)
• Ưu tiên hoá rủi ro (risk prioritization
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 6

7. Thực tế quản lý dự án
• Các công ty phần mềm thành công cũng sẽ phải đối mặt
với các khó khăn to lớn khi thực hiện các dự án lớn hơn,
khách hàng đa dạng hơn, khi lịch biểu được siết chặt
hơn, hoặc khi làm việc trong một miền nghiệp vụ mới mẻ
hơn...
• Vì vậy, bạn cũng nên biết những cách tiếp cận làm yêu
cầu mới có giá trị đối với công việc của bạn.
• Ví dụ: các phương thức làm việc dành cho đội có 5 thành
viên không thể mở rộng áp dụng cho 1 đội có 125 thành
viên rải rác trong các chi nhánh cách xa nhau được.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 7

8. Mối liên hệ giữa yêu cầu và các quy trình
dự án khác
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 8

9. Quy trình Lập kế hoạch dự án
(Project planning process)
• Yêu cầu phải là cơsở của các quy trình lập kế hoạch dự
án.
• Các ước lượng tài nguyên và lịch biểu cần dựa trên sự
hiểu biết về cái gì sẽ được xây dựng và chuyển giao cho
khách hàng.
• Thông thường, lập kế hoạch dự án nghĩa là tính toán sao
cho tất cả các tính năng mong muốn sẽ được thực hiện
trong một giới hạn ngân sách và thời gian nhất định.
• Các quy trình lập kế hoạch có thể dẫn tới việc thu hẹp
phạm vi dự án hoặc lựa chọn một cách tiếp cận từng
bước một - phát hành dần từng phiên bản của sản phẩm,
mỗi phiên bản chỉ bao gồm một số tính năng.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 9

10. Quy trình Giám sát và kiểm soát dự án
(Project tracking and control Process))
• Giám sát (monitor) trạng thái của mỗi yêu cầu được coi là
một phần của việc giám sát dự án (project tracking) sao
cho các nhà quản lý dự án có thể biết liệu công việc có
được tiến hành như mong muốn hay không. Nếu không,
cấp quản lý có thể đề nghị thu hẹp phạm vi thông qua các
quy trình kiểm soát thay đổi.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 10

11. Quy trình Kiểm soát thay đổi
(Change control Process)
Quy trình kiểm soát thay đổi đảm bảo rằng:
• Hiểu rõ ảnh hưởng của một đề xuất thay đổi (proposed
change)
• Tất cả những ai có liên quan đến thay đổi thì đều phải
nhận biết được thay đổi này.
• Những người có thẩm quyền ra quyết định chính thức khi
chấp nhận thay đổi.
• Tài nguyên và các thỏa thuận được điều chỉnh phù hợp.
• Các tài liệu yêu cầu được cất giữ.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 11

12. Quy trình Kiểm thử hệ thống
(System testing process)
• Các yêu cầu người dùng (user requirements) và các yêu
cầu chức năng (functional requirements) là đầu vào chính
để kiểm thử hệ thống.
• Nếu hành vi được mong đợi của phần mềm trong các
điều kiện khác nhau không được đặc tả thì người kiểm
thử rất khó biết hành vi nào của hệ thống là đúng, hành vi
nào là sai.
• Ngược lại, kiểm thử hệ thống là một phương tiện để xác
nhận rằng tất cả các chức năng đã được lập kế hoạch thì
đều được thực hiện và các công việc (tasks) mà người
dùng mong muốn đã hoạt động một cách đúng đắn.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 12

13. Quy trình Làm tài liệu người dùng
(User documentation process)
• Các yêu cầu là đầu vào chính của quy trình làm tài liệu, vì
vậy chất lượng của yêu cầu sẽ quyết định chất lượng của
tài liệu.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 13
Tải bản FULL (29 trang): https://bit.ly/3vgOYuz
Dự phòng: fb.com/TaiHo123doc.net

14. Quy trình Thi công hệ thống
(Construction process)
• Các yêu cầu là cơsở để thiết kế và thi công phần mềm.
Yêu cầu chức năng (functional requirements) dẫn tới các
thiết kế components, chúng phục vụ nhưl à các đặc tả
cho các mã sẽ được viết. Thực hiện soát xét thiết kế để
đảm bảo bản thiết kế đã chứa tất cả các yêu cầu. Kiểm
thử đơn vị (unit testing) mã nguồn có thể xác định liệu nó
có đáp ứng đặc tả thiết kế và yêu cầu tương ứng hay
không.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 14
4252594