zunia.vn

Tuyển sinh 2024 dành cho Gen-Z

zunia.vn

» Tài Chính - Ngân Hàng

» Kế toán - Kiểm toán

Bài giảng Thu nhận yêu cầu: Chương 9 - Trần Thị Kim Chi

Chia sẻ: Hấp Hấp | Ngày: | Loại File: PPT | Số trang:29

Báo xấu

37
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Thu nhận yêu cầu - Chương 9: Software risk management (quản lý rủi ro phần mềm)" trình bày 3 nội dung chính bao gồm: Hazard analysis (HA), threat modeling TM, risk management. Mời các bạn cùng tham khảo nội dung chi tiết.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Thu nhận yêu cầu: Chương 9 - Trần Thị Kim Chi

Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 1 CHƯƠNG 8: SOFTWARE RISK MANAGEMENT QUẢN LÝ RỦI RO PHẦN MỀM
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 2 Nội dung • Hazard analysis (HA) • Threat modeling ™ • Risk management
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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…
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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:
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 8 Mối liên hệ giữa yêu cầu và các quy trình dự án khác
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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ữ.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 15 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.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 16 Yêu cầu và các nhóm Stakeholder
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 17 Yêu cầu và các nhóm Stakeholder • Nhóm marketing (Marketing or Product Management): đặc tả yêu cầu kinh doanh hoặc yêu cầu của thị trường cho nhóm phát triển; đề xuất các thay đổi đối với nhóm phát triển. • Nhóm hỗ trợ kỹ thuật (Technical Support): hỗ trợ người dùng của khách hàng, cung cấp đầu vào cho nhóm phát triển từ việc phân tích các báo cáo lỗi của khách hàng, đề nghị các thay đổi nâng cấp phần mềm. • Người phụ trách dùng (Users): mô tả các yêu cầu người dùng và thuộc tính chất lượng của các yêu cầu đó, soát xét các yêu cầu.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 18 Yêu cầu và các nhóm Stakeholder • Nhóm kỹ thuật phần cứng (Hardware Engineering): đặc tả các giao diện phần cứng mà phần mềm phải làm việc cùng. • Nhóm kỹ thuật hệ thống (Systems Engineering): phân bổ các yêu cầu hệ thống cho phần mềm, đề xuất thay đổi. • Nhóm mua sắm (Procuers): đặc tả các nhu cầu kinh doanh, chức năng và hiệu suất; đề xuất thay đổi. • Nhóm pháp lý (Legal Department): xử lý các vấn đề pháp luật liên quan đến license của các tools và components. • Cấp quản lý (Management): đề ra các ràng buộc của dự án, ràng buộc về tài nguyên và cam kết khác cho nhóm phát triển.
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 19 CƠ BẢN VỀ CẢI TIẾN QUY TRÌNH PHẦN MỀM (FUNDAMENTALS OF SOFTWARE PROCESS IMPROVEMENT) 1. Cải tiến quy trình cần được thực hiện theo kiểu tiến hoá, liên tục và có chu trình (Process improvement should be evolutionary, continuous, and cyclical). 2. Con người và các tổ chức chỉ thay đổi khi họ bị thúc ép phải thay đổi (People and organizations change only when they have an intence to do so). 3. Các thay đổi quy trình cần phải được hướng đích (Process changes should be goal oriented). 4. Xử lý các hoạt động cải tiến quy trình của bạn nhưlà các tiểu dự án (Treat improvement activities as miniprojects).
Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 20 CHU TRÌNH CẢI TIẾN QUY TRÌNH (THE PROCESS IMPROVEMENT CYCLE) Assess Current Practices = Đánh giá các practices hiện tại Plan Improvement Actions = Lập kế hoạch cho các hoạt động cải tiến Create, Pilot and Implement New Processes = Thiết lập, thử nghiệm, cải tiến các quy trình mới Evaluate Results = Đánh giá kết quả

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.