Phân tích và quản lí yêu cầu phần mềm

Phân tích quản lí yêu cầu phần mềm Phân tích yêu cầu Lam Quang Vu Truong Phuoc Loc References: C1.Ebook +John Vu (CMU) Tiến trình phát triển yêu cầu Phân tích yêu cầu  Là kĩ thuật định tính thích hợp cho sản phẩm dựa nhu cầu stakeholder  Để phân tích hiệu yêu cầu, kĩ sư phần mềm cần hiểu, định nghĩa xác minh yêu cầu từ quan điểm stakeholder để xếp hạng độ ưu tiên nhu cầu trước định yêu cầu cho phần mềm  Các yêu cầu phát từ stakeholder phải hoàn thiện rõ ràng cho việc xác minh sau Phân tích yêu cầu  Tiến trình phân tích nhu cầu stakeholder nhằm chuẩn bị cho việc định nghĩa hệ thống yêu cầu phần mềm  Là tiền trính chuyển nhu cầu nghiệp vụ thành mô tả hệ thống với tham số hiệu phân hoạch chúng thành hệ thống để cấp phát phần cứng phần mềm  Do stakeholder nhà phát triển có nhiều quan điểm cách diễn đạt khác nhau, để hiểu tốt hơn, kĩ sư phần mềm nên sử dụng mô tả trừu tượng dễ hiểu diễn giải Các quan điểm khác  Mục tiêu: Định nghĩa hệ thống làm Phân tích yêu cầu  Kết phân tích yêu cầu mơ hình u cầu  Mơ hình u cầu yêu cầu đại diện lược đồ, văn có cấu trúc (danh sách, bảng, ma trận)  Phân tích yêu cầu tập trung vào thỏa hiệp định tính quan trọng tương đối việc xếp hạng độ ưu tiên  Kĩ sư phần mềm chịu trách nhiệm phân tích yêu cầu cộng tác với stakeholders để xếp hạng độ ưu tiên nhu cầu  Là tiến trình lặp Tại phải mơ hình hóa u cầu?  Giao tiếp tốt người làm kĩ thuật kinh doanh  Cho phép nhóm dự án nhìn vào khía cạnh khác u cầu người dùng  Phát yêu cầu thiếu, có lỗi, mập mờ hay mâu thuẫn  Khám phá phụ thuộc lẫn yêu cầu  Cho phép stakeholder thấy tất yêu cầu để hiểu tốt Tiến trình phân tích u cầu  Xem xét tất yêu cầu để đảm bảo chúng khớp với mục đích mục tiêu nghiệp vụ  Định nghĩa phạm vi dự án  Tạo yêu cầu chi tiết sử dụng nhiều mơ hình giúp stakeholder hiểu rõ nhu cầu họ  Xếp hạng độ ưu tiên yêu cầu  Tiếp tục phân tích có nhiều chi tiết xuất  Gán thuộc tính chất lượng yêu cầu phát tinh chế Tiến trình phân tích u cầu Phạm vi & Biên  Phạm vi yêu cầu phải định nghĩa tất yêu cầu định phải hợp lí phạm vi định nghĩa  Chỉ chọn yêu cầu bạn nên giải thích  Bất kì u cầu phát biểu mà phạm vi cần phải xác minh thảo luận với stakeholder để thêm vào hay loại bỏ  Ghi chú: phạm vi “các biên toàn hệ thống”  Các ràng buộc giúp thiết lập phạm vi hệ thống (bien) 10 Vấn đề yêu cầu  Nhiều hệ thống giao trễ vượt ngân sách Chúng thường không thực người dùng muốn thường khơng tận dụng tối đa độ hữu ích  Bước giải vấn đề xác định nguyên nhân gốc rễ  Có nghiên cứu nguyên nhân gốc rễ:  Thiếu liệu đầu vào từ người dùng  Yêu cầu đặc tả không đầy đủ  Thay đổi yêu cầu đặc tả 1/22/2018 Requirement Management 29 29 Chi phí tích lũy yêu cầu khơng tốt / bị bỏ sót 0.1 Requirements 0.5 Design Coding Unit Testing Acceptance Testing 20 Maintenance Chi phí tương đối để sửa chửa sai sót 1/22/2018 RequirementManagement 30 30 Ảnh hưởng vấn đề  Tái đặc tả  Phải định nghĩa lại yêu cầu  Thiết kế lại  Thay đổi mô hình phụ thuộc  Lập trình lại  Phải viết lại mã nguồn  Kiểm thử lại  Thay đổi kế hoạch kiểm thử, trường hợp kiểm thử, kiểm thử lại  Bỏ thêm nhiều nỗ lực thời gian / tài nguyên     1/22/2018 Thu hồi lại / bỏ sản phẩm Legal liability / Khách hàng tức giận Tăng chi phí bảo trì Thay đổi tài liệu Requirement Management 31 31 Thế quản lí yêu cầu tốt? 32 Quản lí yêu cầu tốt  Ngăn ngừa  Chi tiêu mức thời gian  Hủy dự án  Các dự án thành cơng có “nhân tố thành công” sau  Lôi kéo người dùng liên quan  Hỗ trợ từ quản lí điều hành  Phát biểu yêu cầu rõ ràng 1/22/2018 Requirement Management 33 33 Chất lượng yêu cầu: Tính quán  Tính nhấn qn  Khơng có mâu thuẫn  Chương trình khơng hoạt động u cầu mâu thuẫn  Khó đảm bảo  Tập hợp yêu cầu lớn  Các mẫu thuẫn ẩn  Ví dụ: ▪ Mục 1.2 nói: “khơng cần nhiều 128MB nhớ” ▪ Mục 5.8.9 nói: “hình ảnh nên dựng theo thời gian thực” ▪ => có mâu thuẫn khơng???  Logic hình thức: thứ phải tuân theo mâu thuẫn  Vấn đề:  Khó long giải thích mâu thuẫn cho khách hàng  Khách hàng muốn thứ bất khả thi 1/22/2018 Requirement Management 34 34 Chất lượng yêu cầu: Có thể quản lí  Các tài ngun phải đáp ứng u cầu  Có thể hồn thiện khơng?  Với số tiền có?  Với kĩ có?  Quản lí rủi ro  Các yêu cầu nên xếp hạng ưu tiên  Lí tưởng: có thêm lựa chọn thay  Thường khơng thể nói u cầu khả thi  Quản lí độ phức tạp  Đừng làm thứ lúc  Tiến trình lặp  Tạo nguyên mẫu 1/22/2018 Requirement Management 35 35 Chất lượng yêu cầu: Cụ thể  Chính xác chi tiết  Khơng tốt:  “Chương trình phải nhanh”  “Nhận liệu đầu vào số”  Tốt:  “Chương trình nên hồi đáp nhỏ 1s”  “Dữ liệu đầu vào số nguyên không dấu 16 bit”  Tạo định nghĩa  Ví dụ: “Khi nói tới ‘Số', có nghĩa số nguyên có dấu 16-bit”  Các thuật ngữ định nghĩa thường viết hoa  Qui tắc định nghĩa  Khơng tham chiếu vòng 1/22/2018 Requirement Management 36 36 Chất lượng u cầu: Khơng có thành kiến cài đặt  Thành kiến cài đặt:  Cung cấp thông tin cách thiết kế  Cung cấp thông tin cách lập trình  Sử dụng thuật ngữ miền  Không dùng thuật ngữ kĩ thuật  Bạn muốn tập trung vào WHAT  Để HOW sau  Ví dụ khơng tốt:  “Lưu trữ sách trả vào mảng”  “Tính bậc hai với thuật tốn Newton”  Ví dụ tốt:  “Thư viện biết sách trả”  “Trả bậc hai với độ xác chữ số” 1/22/2018 Requirement Management 37 37 Yêu cầu phải …  Đúng: Phải đại diện nhu cầu thực tiễn khách hàng người dùng  Đầy đủ: Bao gồm tất yếu tố cần thiết  Chức năng, giao diện bên ngồi, thuộc tính chất lượng ràng buộc thiết kế  Rõ ràng: Có thể hiểu giống mà cần giải thích tối thiểu cho stakeholder  Chính xác: Được phát biểu đơn giản, theo cách tối thiểu để hiểu  Nhất quán: không mâu thuẫn với yêu cầu khác 1/22/2018 Requirement Management 38 38 Yêu cầu cần phải…  Hợp lí: cần thiết để đáp ứng nhu cầu, mục đích, mục tiêu nghiệp vụ  Khả thi: cài đặt  Xác minh được: dùng kĩ thuật xác định, tiết kiệm chi phí để định yêu cầu thỏa hay chưa 1/22/2018 Requirement Management 39 39 Cơ chế phân tích            Persistency Giao tiếp(IPC and RPC) Định tuyến thơng điệp Phân phối Quản lí giao tác Điều khiển đồng tiến trình (tranh chấp tài nguyên) Trao đổi thông tin, chuyển đổi định dạng Bảo mật Dò tìm / xử lí / báo cáo lỗi Tính dư thừa Giao diện truyền thống 40 Cơ chế phân tích Các đặc điểm  Persistency       Độ mịn Độ lớn Thời gian Cơ chế đánh giá Độ trễ đánh giá (tạo / xóa, cập nhật, đọc) Độ tin cậy  Giao tiếp     Độ trễ Khả đồng Kích thước thông điệp Giao thức 41  Giao diện truyền thống     Độ trễ Thời gan Cơ chế truy cập Độ trễ truy cập  Bảo mật     Độ mịn liệu Độ mịn người dùng Các luật bảo mật Các loại quyền hạn 42 Hoạt động  Xác định chế phân tích mà bạn nghĩ quan trọng dự án  Tạo câu hỏi chế để làm rõ kì vọng bạn 43 ... phát triển u cầu Phân tích u cầu  Là kĩ thuật định tính thích hợp cho sản phẩm dựa nhu cầu stakeholder  Để phân tích hiệu yêu cầu, kĩ sư phần mềm cần hiểu, định nghĩa xác minh yêu cầu từ quan... hạng độ ưu tiên nhu cầu trước định yêu cầu cho phần mềm  Các yêu cầu phát từ stakeholder phải hoàn thiện rõ ràng cho việc xác minh sau Phân tích u cầu  Tiến trình phân tích nhu cầu stakeholder... chế Tiến trình phân tích yêu cầu Phạm vi & Biên  Phạm vi yêu cầu phải định nghĩa tất yêu cầu định phải hợp lí phạm vi định nghĩa  Chỉ chọn u cầu bạn nên giải thích  Bất kì yêu cầu phát biểu