Bài giảng Công nghệ phần mềm - Phần 3: Phương pháp xác định yêu cầu người dùng cung cấp cho người học các kiến thức: 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, công cụ và phương pháp đặc tả yêu cầu phần mềm,.. Mời các bạn cùng tham khảo nội dung chi tiết.
9/13/2011 PHẦN III: PHƯƠNG PHÁP XÁC ĐỊNH YÊU CẦU NGƯỜI DÙNG I Tổng quan yêu cầu phần mềm II Quy trình xác định u cầu phần mềm III Cơng cụ phương pháp đặc tả yêu cầu phần mềm IV Nguyên lý phân tích yêu cầu sử dụng 1 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 phần mềm - nêu Xác đị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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 Tại cần phải đặt yêu cầu phần mềm ? • Khách hàng có ý tưởng mơ hồ phần mềm cần phải xây dựng để phục vụ công việc họ, 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ý Phân loại • Theo thành phần phần mềm: – – – – Các Các Các Các yêu yêu yêu yêu cầu cầu cầu cầu về về phần mềm (Software) phần cứng (Hardware) liệu (Data) người (People, Users) • Theo cách đặc tả phần mềm – Các yêu cầu chức – Các yêu cầu chức – Các ràng buộc khác CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 II Quy trình xác định yêu cầu PM • Phát yêu cầu phần mềm (Requirements elicitation) • Phân tích yêu cầu phần mềm thương lượng với khách hàng (Requirements analysis and negotiation) • Đặc tả 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) Ví dụ: Quy trình xác định u cầu phần mềm hướng đối tượng Requirements Elicitation Requirements Analysis System Design Expressed in Terms Of Structured By Object Design Implementation Implemented By Realized By Verified By class class class Use Case Model Application Implementat Domain SubSystems ion Domain Objects Objects ? class ? Source Code Or textual requirements CuuDuongThanCong.com Testing Test Cases https://fb.com/tailieudientucntt 9/13/2011 Phát 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 (chun 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 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) 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 yêu cầu 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õ yêu cầu CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 Đầu bước phát yêu cầu phần mềm • 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 Customer Group Software Engineering Group Phân tích yêu cầu PM thương lượng với khách hàng 10 CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 Phân tích yêu cầu PM 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 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ầm mềm để xác định chúng có khả thực mơi trường kỹ thuật hay khơng, có khả kiểm định yêu cầu phần mềm hay không 11 Phân tích yêu cầu PM thương lượng với khách hàng • 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 đề 12 CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 Đặc tả yêu cầu phần mềm • • Đặ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ả: – Đặ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 đồ • 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 13 Ví dụ: Các u cầu hồ sơ đặc tả Đặc tả hành vi bên HT Đặc tả ràng buộc cài đặt Dễ thay đổi Dùng công cụ tham khảo cho bảo trì Sự ghi chép cẩn thận vịng đời HT, nghĩa dự đốn thay đổi • Các đáp ứng với cố khơng mong đợi • • • • • 14 CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 3.1 Các thành phần hồ sơ đặc tả • Đặ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: – 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ể sao, – Hành vi hệ thống tình đặc biệt • Đặ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 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,… • 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 15 Đặc tả chức • 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 – Tương tác phần mềm môi trường, độc lập với việc cài đặt – Ví dụ: The watch system must display the time based on its location • Các cơng cụ đặc tả tiêu biểu: – – – – 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 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 Đặ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: – Các tính chất hệ thống độ tin cậy, thời gian trả lời, dung lượng nhớ, … • The response time must be less than second • Ràng buộc: khách hàng hay môi trường thực thi phần mềm đặt – 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, … • The implementation language must be COBOL – Các u cầu từ bên ngồi • Must interface to the dispatcher system written in 1956 • Thường sử dụng cơng cụ Khó phát biểu xác, Rất khó kiểm tra – Biểu đồ thực thể liên kết (Entity-Relationship Diagrams) – Đặc tả Logic (Logic Specifications) – Đặc tả đại số (Algebraic Specifications) 17 3.2 Tài liệu yêu cầu • 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 • 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) 18 CuuDuongThanCong.com https://fb.com/tailieudientucntt 9/13/2011 Nội dung cần có tài liệu yêu cầu System customers Specify t he req uiremen ts and read th em to ch eck that they meet th eir n eeds Th ey specify changes to the requ irements Managers Use the requirements d ocumen t to pl an a bid for the s ys tem and to plan th e sy stem developmen t p rocess System engineers Use the requirements to understan d wh at s ystem i s to b e dev elo ped System test engineers Use the req uirements to d ev elo p valid ation tes ts for t he system System maintenance engineers Us e t he requirement s to help understan d th e system and the relationsh ip s b etween its parts 19 III Phương pháp công cụ đặc tả yêu cầu phần mềm • 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) 20 CuuDuongThanCong.com https://fb.com/tailieudientucntt 10 9/13/2011 Đặ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: Thể chức (functions) Thể luồng liệu Kho liệu Vào liệu tương tác hệ thống người sử dụng 21 Ví dụ: mơ tả biểu thức tốn học DFD (a+b)*(c+a*d)-e*(a+b) b c a + a d * + * 22 CuuDuongThanCong.com https://fb.com/tailieudientucntt 11 9/13/2011 Ví dụ đặc tả chức thư viện qua DFD Yêu cầu từ người mượn Tên sách, tác giả Tên người mượn Sách Kho sách Tên tác giả Danh sách tác giả Tên sách Danh sách tên sách Có sách Sách Thơng tin sách Tên sách; Tên người mượn Danh sách người mượn Danh sách chủ đề Tìm theo chủ đề Liệt kê tên sách liên quan đến chủ đề Chủ đề Chủ đề yêu cầu Đưa Tên sách 23 Các hạn chế DFD • Ý 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: 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 24 CuuDuongThanCong.com https://fb.com/tailieudientucntt 12 9/13/2011 Các hạn chế DFD • Trong DFD khơng xác định rõ hướng thực (control aspects) A B E D F C • Biểu đồ DFD khơng rõ đầu vào để thực chức D đầu sau thực chức D • 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 25 Các hạn chế DFD • DFD khơng xác định đồng chức / mô-đun – 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 A B 26 CuuDuongThanCong.com https://fb.com/tailieudientucntt 13 9/13/2011 Đặc tả trạng thái với FSM - Finite State Machines • FSM chứa – 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 • δ:QxIQ High pressure alarm High temp alarm ON OFF Restart 27 Ví dụ: thư viện • 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ả, 28 CuuDuongThanCong.com https://fb.com/tailieudientucntt 14 9/13/2011 Đặc tả yêu cầu đặc biệt thư viện • Độ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 • Một số người khơng mượn số loại sách đó, 29 Đặc tả đối tượng thư viện • Các đối tượng: – – – – Tên sách Mã Nhân viên phục vụ Người mượn • 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 30 CuuDuongThanCong.com https://fb.com/tailieudientucntt 15 9/13/2011 FSM đặc tả trạng thái • Ta có tập hợp sách (mỗi đầu sách có nhiều sách thư viện) • Mỗi sách có trạng thái sau: – – – – (AV) Available: phép mượn, (CO) - (BR): mượn (Check Out; Borrow), (L): Last, (R): Remove CO AV BR L R Có thể có hạn chế số sách mượn cho nhóm độc giả độc giả, 31 Đặc tả liệu với Mơ hình thực thể liên kết -ERD • 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 – Thực thể – Quan hệ – Thuộc tính • Biểu đồ thực thể 32 CuuDuongThanCong.com https://fb.com/tailieudientucntt 16 9/13/2011 Thực thể • 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ệ: – person owns car Person Car Owns • Thực thể có thuộc tính 33 Thuộc tính • Tính chất thực thể đối tượng liệ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 Ford Car Automobile Company Blue ID Ford Tập thuộc tính đối tượng liệu xác định thông qua ngữ cảnh toán 34 CuuDuongThanCong.com https://fb.com/tailieudientucntt 17 9/13/2011 Quan hệ • Chỉ mối liên quan gữa đối tượng liệu Bookstore N Orders Books Cardinality : định lượng mối quan hệ 1:1 one-to-one Modality : 1:N one-to-many M:N many-to-many – có, khơng có quan hệ – bắt buộc có quan hệ Customer Is provided with N Repair Action 35 Ví dụ: ERD mơ tả thư viện Area N Deals with Copy Belongs to N N Title Written by state Text Was held by holds Author M Borrower limit 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt 18 9/13/2011 Thế đặc tả tốt? • • • • • Dễ hiểu với người dùng Có điều nhập nhằng Có quy ước mơ tả, tạo đơn giản Với phong cách từ xuống (topdown) 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, 37 Mơ hình hóa liệu • Xác định đối tượng liệu • Xác định đặc tính đối tượng liệu • Thiết lập mối quan hệ đối tượng liệu 38 CuuDuongThanCong.com https://fb.com/tailieudientucntt 19 9/13/2011 Mơ hình hóa chức • Xác định chức chuyển đổi đối tượng liệu • Chỉ luồng liệu qua hệ thống • Biểu diễn phận sản sinh liệu phận tiêu thụ liệu 39 Mơ hình hóa hành vi – 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 40 CuuDuongThanCong.com https://fb.com/tailieudientucntt 20 9/13/2011 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 • Tạo phân cấp chức • Biểu diễn hành vi (behavior) mức chi tiết khác 41 Bản chất • 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 42 CuuDuongThanCong.com https://fb.com/tailieudientucntt 21 ... Theo thành phần phần mềm: – – – – Các Các Các Các yêu yêu yêu yêu cầu cầu cầu cầu về về phần mềm (Software) phần cứng (Hardware) liệu (Data) người (People, Users) • Theo cách đặc tả phần mềm –... định 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) Phát yêu cầu phần mềm • Xác định phương pháp... lượng mối quan hệ 1:1 one-to-one Modality : 1:N one-to-many M:N many-to-many – có, khơng có quan hệ – bắt buộc có quan hệ Customer Is provided with N Repair Action 35 Ví dụ: ERD mơ tả thư viện