Đang tải... (xem toàn văn)
Chương 6 - Kỹ nghệ yêu cầu phần mềm (Requirement Engineering). Chương này cung cấp cho người học những kiến thức cơ bản về: Tổng quan về yêu cầu phần mềm, quy trình xác định yêu cầu phần mềm, phương pháp và công cụ đặc tả yêu cầu phần mềm, nguyên lý phân tích yêu cầu sử dụng.
Chương 5: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) • Tổng quan yêu cầu phần mềm • Quy trình xác định yêu cầu phần mềm NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (INTRODUCTION TO SOFTWARE ENGINEERING) co ng c om • Phương pháp cơng cụ đặc tả yêu cầu phần mềm • Nguyên lý phân tích yêu cầu sử dụng an ng th Mục đích xác định yêu cầu phần mềm du o Khái niệm • Các đặc tính hệ thống hay sản phẩm khách hàng - người sử dụng PM - đặt Xác u • Khách hàng có ý tưởng cịn mơ hồ phần mềm cần phải xây dựng để phục vụ cơng việc họ • Cho nên phải sẵn sàng, kiên trì theo đuổi để từ ý tưởng mơ hồ đến “Phần mềm có đầy đủ tính cần thiết” • Khách hàng hay thay đổi địi hỏi mình, nắm bắt thay đổi sửa đổi mô tả cách hợp lý cu định phần mềm đáp ứng yêu cầu mong muốn khách hàng - người sử dụng phần mềm Lĩnh vực ứng dụng hệ thống/sản phẩm Nhu cầu ràng buộc người có quyền lợi nghĩa vụ liên quan đến hệ thống /sản phẩm Bài toán khách hàng cần giải Ngữ cảnh nghiệp vụ: tương tác hệ thơng/sản phẩm đóng góp mặc nghiệp vụ hệ thống 3 4 CuuDuongThanCong.com https://fb.com/tailieudientucntt Phân loại yêu cầu Quy trình xác định yêu cầu PM • Theo thành phần phần mềm: • Phát yêu cầu phần mềm (Requirements elicitation) • Phân tích u cầu phần mềm thương lượng với khách hàng (Requirements analysis and negotiation) • Đặc tả yêu cầu phần mềm (Requirements specification) • Mơ hình hóa hệ thống (System modeling) • Kiểm tra tính hợp lý yêu cầu phần mềm (Requirements validation) • Quản trị yêu cầu phần mềm (Requirements management) c om – Các yêu cầu phần mềm (Software) – Các yêu cầu phần cứng (Hardware) – Các yêu cầu liệu (Data) – Các yêu cầu người (People, Users) • Theo cách đặc tả phần mềm co ng – Các yêu cầu chức – Các yêu cầu chức – Các ràng buộc khác an ng th Phát yêu cầu phần mềm • Đánh giá tính khả thi kỹ thuật nghiệp vụ phần mềm định phát triển • Tìm kiếm nhân (chuyên gia, người sử dụng) có hiểu biết sâu sắc nhất, chi tiết hệ thống giúp xác định yêu cầu phần mềm • Xác định mơi trường kỹ thuật triển khai phần mềm • Xác định ràng buộc lĩnh vực ứng dụng phần mềm (giới hạn chức năng/hiệu phần mềm) Vấn đề Xác định yêu cầu cu u Xây dựng nguyên mẫu (prototype) du o Quy trình xác định yêu cầu PM (tiếp) Phát triển đặc điểm kỹ thuật Xem duyệt Tạo mô hình phân tích Last Update8-07 Dept of SE, 2002 SE-III.7 8 CuuDuongThanCong.com https://fb.com/tailieudientucntt Đầu bước phát yêu cầu phần mềm • Xác định phương pháp sử dụng để phát yêu cầu phần mềm: vấn, làm việc nhóm, buổi họp, gặp gỡ đối tác, v.v • Thu hút tham gia nhiều chuyên gia, khách hàng để có quan điểm xem xét phần mềm khác từ phía khách hàng • Xác định u cầu cịn nhập nhằng để làm mẫu thử • Thiết kế kịch sử dụng phần mềm để giúp khách hàng định rõ u cầu • Bảng kê (statement) đòi hỏi chức khả thi phần mềm • Bảng kê phạm vi ứng dụng phần mềm • Mơ tả mơi trường kỹ thuật phần mềm • Bảng kê tập hợp kịch sử dụng phần mềm • Các nguyên mẫu xây dựng, phát triển hay sử dụng phần mềm (nếu có) • Danh sách nhân tham gia vào trình phát yêu cầu phần mềm - kể nhân từ phía cơng ty- khách hàng co ng c om Phát yêu cầu phần mềm an 10 th 10 Phân tích yêu cầu phần mềm thương lượng với khách hàng Nhóm khách hàng Phân tích u Cần thiết ? Nhất quán + đầy đủ ? Khả thi ? cu Nhóm cơng nghệ phần mềm du o ng Phân tích yêu cầu PM thương lượng với khách hàng Yêu cầu không cần thiết Yêu cầu không đầy đủ, yêu cầu mâu thuẫn Yêu cầu không khả thi Thương lượng Thảo luận yêu cầu Đặt thứ tự ưu tiên cho yêu cầu 11 11 12 12 CuuDuongThanCong.com Nhất trí yêu cầu https://fb.com/tailieudientucntt Phân tích yêu cầu phần mềm thương lượng với khách hàng • Phân loại yêu cầu phần mềm xếp chúng theo nhóm liên quan • Khảo sát tỉ mỉ yêu cầu phần mềm mối quan hệ với yêu cầu phần mềm khác • Thẩm định yêu cầu phần mềm theo tính chất: phù hợp, đầy đủ, rõ ràng, khơng trùng lặp • Phân cấp yêu cầu phần mềm theo dựa nhu cầu đòi hỏi khách hàng / người sử dụng • Thẩm định yêu cầu phần mềm để xác định: • Thẩm định rủi ro xảy với yêu cầu phần mềm • Đánh giá thô (tương đối) giá thành thời gian thực yêu cầu phần mềm giá thành sản phẩm phần mềm thời gian thực phần mềm • Giải tất bất đồng yêu cầu phần mềm với khách hàng / người sử dụng sở thảo luận thương lượng yêu cầu đề c om Phân tích yêu cầu phần mềm thương lượng với khách hàng co ng – Các yêu cầu PM có khả thực môi trường kỹ thuật hay khơng – Có khả kiểm định u cầu phần mềm hay khơng an 13 14 Ví dụ: Các yêu cầu hồ sơ đặc tả du o Đặc tả yêu cầu phần mềm ng th 13 14 • Đặc tả yêu cầu phần mềm: xây dựng tài liệu đặc tả, sử dụng tới cơng cụ như: mơ hình hóa, mơ hình tốn học hình thức (a formal mathematical model), tập hợp kịch sử dụng, nguyên mẫu tổ hợp cơng cụ nói • Phương pháp đặc tả: u • Đặc tả hành vi bên ngồi HT • Đặc tả ràng buộc cài đặt cu • Dễ thay đổi • Dùng cơng cụ tham khảo cho bảo trì – Đặc tả phi hình thức (Informal specifications): viết ngơn ngữ tự nhiên – Đặc tả hình thức (Formal specifications): viết tập ký pháp có quy định cú pháp (syntax) ngữ nghĩa (sematic) chặt chẽ, thí dụ ký pháp đồ họa dùng lưu đồ • Sự ghi chép cẩn thận vịng đời HT, nghĩa dự đốn thay đổi • Tiêu chí đánh giá chất lượng hồ sơ đặc tả: – Tính rõ ràng, xác – Tính phù hợp – Tính đầy đủ, hồn thiện • Các đáp ứng với cố không mong đợi 15 15 16 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt Các thành phần hồ sơ đặc tả Đặc tả chức • Đặc tả vận hành hay đặc tả chức (Operational specifications): mô tả hoạt động hệ thống phần mềm xây dựng: • Miêu tả chức hệ thống, phụ thuộc vào kiểu phần mềm mong đợi người dùng – Các dịch vụ mà hệ thống phải cung cấp – Hệ thống phản ứng với đầu vào cụ thể – Hành vi hệ thống tình đặc biệt – Tương tác phần mềm môi trường, độc lập với việc cài đặt – Ví dụ: Hệ thống đồng hồ phải hiển thị thời gian dựa vị trí c om • Đặc tả mơ tả hay đặc tả phi chức (Descriptive specifications): đặc tả đặc tính, đặc trưng phần mềm: • Các cơng cụ đặc tả tiêu biểu: – Các ràng buộc dịch vụ hay chức hệ thống cung cấp thời gian, ràng buộc trình phát triển, chuẩn,… – – – – co ng • Ngồi cịn có u cầu lĩnh vực, bắt nguồn từ lĩnh vực ứng dụng hệ thống đặc trưng lĩnh vực Biểu đồ luồng liệu (Data Flow Diagrams) Máy trạng thái hữu hạn (Finite State Machines) Mạng Petri (Petri nets),… Tuy nhiên không bắt buộc dùng ngơn ngữ tự nhiên an 17 18 ng th 17 18 • Tài liệu yêu cầu du o Đặc tả phi chức ràng buộc Yêu cầu phi chức năng: Định nghĩa khía cạnh sử dụng phần mềm, không liên quan trực tiếp tới hành vi chức năng: • Tài liệu yêu cầu phát biểu thức yêu cầu nhà phát triển HT • Nó bao gồm phần: định nghĩa đặc tả yêu cầu • Thời gian trả lời phải nhỏ giây Ràng buộc: khách hàng hay môi trường thực thi phần mềm đặt cu • u – Các tính chất hệ thống độ tin cậy, thời gian trả lời, dung lượng nhớ, … – Các yêu cầu tổ chức qui định qui định chuẩn trình tiến hành, chuẩn tài liệu, … • Ngơn ngữ cài đặt phải COBOL • Nó khơng phải tài liệu thiết kế Tốt tập mà HT phải làm HT phải làm (PT TK) – Các yêu cầu từ bên ngồi • Phải giao tiếp với hệ thống điều phối viết vào năm 1956 • Thường sử dụng công cụ – Biểu đồ thực thể liên kết (Entity-Relationship Diagrams) – Đặc tả Logic (Logic Specifications) – Đặc tả đại số (Algebraic Specifications) Khó phát biểu xác, Rất khó kiểm tra 19 19 20 20 CuuDuongThanCong.com https://fb.com/tailieudientucntt Phương pháp công cụ đặc tả yêu cầu phần mềm Nội dung cần có tài liệu yêu cầu Sử dụng tài liệu yêu cầu để lên kế hoạch đấu thầu cho hệ thống lên kế hoạch cho trình phát triển hệ thống Kỹ sư hệ thống Sử dụng yêu cầu để hiểu hệ thống phát triển Kỹ sư kiểm thử hệ thống Sử dụng yêu cầu để phát triển trường hợp kiểm thử cho hệ thống Kỹ sư bảo trì hệ thống Sử dụng yêu cầu để hiểu hệ thống mối liên hệ phấn khác hệ thống c om Nhà quản lý • Biểu đồ phân cấp chức - WBS (work break down structure) • Biểu đồ luồng liệu – DFD (data flow diagram) • Máy trạng thái – FSM (Finite state machine) • Sơ đồ thực thể liên kết – ERD (entity relation diagram) ng Xác định yêu cầu, đọc hiểu để kiểm tra xem có với nhu cầu hay không Họ xác định thay đổi yêu cầu co Khách hàng hệ thống an 21 22 th 21 22 ng Ví dụ: mơ tả biểu thức toán học DFD du o Đặc tả chức với DFD • Hệ thống (System): tập hợp liệu (data) xử lý chức tương ứng (functions) • Các ký pháp sử dụng: u (a+b)*(c+a*d)-e*(a+b) cu b a Thể chức (functions) + a d * c + Thể luồng liệu Kho liệu * Vào liệu tương tác hệ thống người sử dụng 23 23 24 24 CuuDuongThanCong.com https://fb.com/tailieudientucntt Ví dụ đặc tả chức thư viện qua DFD Các hạn chế DFD Yêu cầu từ người mượn • Ý nghĩa ký pháp sử dụng xác định định danh lựa chọn NSD • Ví dụ: DFD chức tìm kiếm sách: Tên sách, tác giả Tên người mượn Sách Kho sách Sách Có sách Danh sách tác giả Tên sách Thông tin sách Tên sách; Tên người mượn Danh sách tên sách Danh sách người mượn Tìm theo chủ đề Liệt kê tên sách liên quan đến chủ đề ng Danh sách chủ đề Chủ đề Đưa Tên sách co Chủ đề yêu cầu If NSD nhập vào tên tác giả tiêu đề sách Then tìm kiếm sách tương ứng, khơng có thơng báo lỗi Elseif nhập tên tác giả Then hiển thị danh sách sách tương ứng với tên tác giả nhập yêu cầu NSD lựa chọn sách Elseif nhập tiêu đề sách Then Endif c om Tên tác giả an 25 26 A B E • • • • D F C • • Chức D cần A, B C Chức D cần A, B C để thực Chức D kết xuất kết cho E F Chức D kết xuất kết chung cho E F Chức D kết xuất kết riêng cho E F • DFD khơng xác định đồng chức / mô-đun u Trong DFD không xác định rõ hướng thực (control aspects) – A xử lý liệu B hưởng (nhận) kết xử lý từ A – A B chức khơng đồng (asynchronous activities) cần có buffer để ngăn chặn tình trang liệu cu • Các hạn chế DFD du o Các hạn chế DFD ng th 25 26 Biểu đồ DFD khơng rõ đầu vào để thực chức D đầu sau thực chức D A B 27 27 28 28 CuuDuongThanCong.com https://fb.com/tailieudientucntt Đặc tả trạng thái với FSM - Finite State Machines Ví dụ: quản lý thư viện • FSM chứa • Xét giao dịch: – Mượn sách / Trả sách – Thêm đầu sách / Loại bỏ đầu sách – Liệt kê danh sách đầu sách theo tên tác giả hay theo chủ đề – Tìm kiếm sách theo yêu cầu người mượn – Tìm kiếm sách hạn trả, c om – Tập hữu hạn trạng thái Q – Tập hữu hạn đầu vào I – Các chức chuyển tiếp δ:QxIàQ • Báo động áp lực cao ng Báo động nhiệt độ cao OFF Khởi động lại co ON an 29 30 Đặc tả đối tượng du o Đặc tả yêu cầu ng th 29 30 • Các đối tượng: • Độc giả không mượn số lượng sách định, thời gian định • Một số sách khơng mượn cu u – Tên sách – Mã – Nhân viên phục vụ – Người mượn • Một số người khơng mượn số loại sách đó, • Cần có: – tập hợp (danh sách) tiêu đề sách – danh sách tác giả cho sách, – danh sách chủ đề liên quan sách 31 31 32 32 CuuDuongThanCong.com https://fb.com/tailieudientucntt FSM đặc tả trạng thái Đặc tả liệu với Mơ hình thực thể liên kết -ERD • Mỗi sách có trạng thái sau: • Mơ hình khái niệm cho phép đặc tả yêu cầu logic hệ thống, thường sử dụng hệ thống liệu lớn • ER Model c om • Ta có tập hợp sách (mỗi đầu sách có nhiều sách thư viện) – (AV) Available: phép mượn, – (CO) - (BR): mượn (Check Out; Borrow), – (L): Last, CO AV BR – (R): Remove ng • Biểu đồ thực thể R co L – Thực thể – Quan hệ – Thuộc tính 33 an Có thể có hạn chế số sách mượn cho nhóm độc giả độc giả, 34 Thuộc tính du o Thực thể ng th 33 34 • Tính chất thực thể đối tượng liệu • Thực thể : tập hợp thông tin liên quan cần xử lý phần mềm • Thực thể có mối quan hệ: cu u – đặt tên cho mẫu (instance) đối tượng liệu – mô tả mẫu (instance) – tạo liên kết (reference) đến mẫu khác – người sở hữu ơtơ Người sở hữu Ơtơ Ford Car Automobile Company Blue Ford ID • Thực thể có thuộc tính Tập thuộc tính đối tượng liệu xác định thông qua ngữ cảnh toán 35 35 36 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt Quan hệ Ví dụ: ERD mơ tả thư viện Area • Chỉ mối liên quan gữa đối tượng liệu Bookstore N Orders N Deals with Books Copy Belongs to c om Ø Cardinality : định lượng mối quan hệ 1:1 one-to-one 1:N one-to-many M:N many-to-many Ø Modality : – có, khơng có quan hệ Written by N N Repair Action state Text Was held by holds Author M Borrower limit co Customer ng – bắt buộc có quan hệ Is provided with N Title an 37 38 ng th 37 38 FSM ERD Đơn giản, dễ hiểu Có thể phức tạp với số lượng trạng thái lớn Đơn giản, dễ hiểu Không xác định rõ hướng thực Khơng thể tính hay song song tiến trình • Dễ hiểu với người dùng • Có điều nhập nhằng u DFD Mơ tả trạng thái thực thể • Có quy ước mơ tả, tạo đơn giản • Với phong cách từ xuống (topdown) cu Mô tả luồng liệu Thế đặc tả tốt? du o So sánh Xác định rõ hướng thực Thể tốt tính song song Mơ tả trừu tượng sở liệu Không xác định rõ hướng thực • Dễ triển khai cho pha sau vòng đời: thiết kế hệ thống thiết kế chương trình giao diện dễ làm, đảm bảo tính qn, Khơng thể tính hay song song 39 39 40 40 CuuDuongThanCong.com https://fb.com/tailieudientucntt Thế đặc tả tốt? 2.1 Order Customer Need to establish D Customer Master Verify Customer Valid Khách hàng Khách hàng Hoá đơn 2.2 Hệ thống đặt hàng Mặt hàng Customer Kho hàng Phiếu hàng Order Notify c om Đặt hàng co ng Thông báo chuyển hàng an 41 Update 2.4 Valid Item 2.3 Avail Update Commit Check Available D Back Order Back Order D Shipping Taxes Tax 2.5 Create Order Ord D Inventory Master Pending Order 42 42 th 41 D Inventory Master Verify Item ng Nguyên lý phân tích u cầu sử dụng du o • Xác định chức chuyển đổi đối tượng liệu • Chỉ luồng liệu qua hệ thống u Mơ hình hóa liệu • Xác định đối tượng liệu Mơ hình hóa chức cu • Xác định đặc tính đối tượng liệu • Thiết lập mối quan hệ đối tượng liệu • Biểu diễn phận sản sinh liệu phận tiêu thụ liệu 43 43 44 44 CuuDuongThanCong.com https://fb.com/tailieudientucntt Mơ hình hóa hành vi Phân mảnh mơ hình • Tinh lọc mơ hình để biểu diễn mức trừu tượng thấp • Lọc đối tượng liệu c om • Chỉ trạng thái (states) khác hệ thống • Đặc tả tượng (events) làm hệ thống thay đổi trạng thái co ng • Tạo phân cấp chức • Biểu diễn hành vi (behavior) mức chi tiết khác an 45 46 ng th 45 46 du o Bản chất việc phân tích cu u • Hãy bắt đầu cách tập trung vào chất vấn đề không xem xét chi tiết cài đặt 47 47 CuuDuongThanCong.com https://fb.com/tailieudientucntt ... quan gữa đối tượng liệu Bookstore N Orders N Deals with Books Copy Belongs to c om Ø Cardinality : định lượng mối quan hệ 1:1 one -to- one 1:N one -to- many M:N many -to- many Ø Modality : – có, khơng... cầu phần mềm để xác định: • Thẩm định rủi ro xảy với yêu cầu phần mềm • Đánh giá thô (tương đối) giá thành thời gian thực yêu cầu phần mềm giá thành sản phẩm phần mềm thời gian thực phần mềm. .. cầu phần mềm - kể nhân từ phía cơng ty- khách hàng co ng c om Phát yêu cầu phần mềm an 10 th 10 Phân tích yêu cầu phần mềm thương lượng với khách hàng Nhóm khách hàng Phân tích u Cần thiết ? Nhất