Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering): Chương 6 - Nguyễn Nhất Hải

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:12

Thêm vào BST

Báo xấu

37
lượt xem 2
download

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

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ủ đề:

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

Lưu

Nội dung Text: Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering): Chương 6 - Nguyễn Nhất Hải

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