Nhập môn Công nghệ phần mềm - Chương 5: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)

Nội dung text: Nhập môn Công nghệ phần mềm - Chương 5: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)

1. 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 ENGINEERING) phần mềm • 4. Nguyên lý phân tích yêu cầu sử dụng 1 2 1 2 Khái niệm Mục đích xác định yêu cầu phần mềm • 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ụ định được phần mềm đáp ứng được các yêu cầu và mong công việc của họ. 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 Bài toán của khách mềm có đầy đủ các tính năng cần thiết” Lĩnh vực ứng dụng 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ó của hệ thông/sản phẩm và đóng quyền lợi và nghĩa vụ 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
2. 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 – 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 • 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 management) – Các ràng buộc khác 5 6 5 6 Quy trình xác định yêu cầu PM (tiếp) Phát hiện yêu cầu phần mềm 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 sử dụng) có những hiểu biết sâu sắc nhất, Xác định Phát triển chi tiết nhất về hệ thống giúp chúng ta xác Vấn đề Xem 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ẽ triển khai phần mềm Tạo ra mô hình • Xác định các ràng buộc về lĩnh vực ứng dụng phân tích 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
3. Đầ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 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ó) 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 giúp khách hàng định rõ các yêu cầu chính. ty- khách hàng 9 10 9 10 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 thương lượng với khách hàng Phân tích Cần Nhất quán + Khả thiết ? hàng đầy đủ ? thi ? công ph ầ n khách Nhóm Nhóm ngh ệ 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
4. 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 cầu phần mềm • Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan 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á phù hợp, đầy đủ, rõ ràng, không trùng lặp thành sản phẩm phần mềm và thời gian thực • Phân cấp các yêu cầu phần mềm theo dựa trên nhu cầu và đòi hỏi khách hàng / người sử dụng hiện phần mềm • 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 trường kỹ thuật hay không mềm với khách hàng / người sử dụng trên cơ sở – 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 13 14 13 14 Đặc tả yêu cầu phần mềm Ví dụ: Các yêu cầu về hồ sơ đặc tả • Đặ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 • Phương pháp đặc tả: – Đặc tả phi hình thức (Informal specifications): viết bằng ngôn ngữ tự • Dễ thay đổi 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
5. 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ị 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 chuẩn, – Biểu đồ luồng dữ liệu (Data Flow Diagrams) • 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ự nhiên. 17 18 17 18 Đặc tả phi chức năng và ràng buộc Tài liệu yêu cầu • 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 • 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ả – 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 • Nó không phải là tài liệu thiết kế. Tốt hơn có • Phải giao tiếp với hệ thống điều phối được viết vào năm 1956. • 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
6. 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 • Biểu đồ phân cấp chức năng - WBS (work định các thay đổi về yêu cầu. break down structure) Sử dụng tài liệu về yêu cầu để lên kế hoạch Nhà quản lý đấu thầu cho hệ thống và lên kế hoạch cho • Biểu đồ luồng dữ liệu – DFD (data flow quá trình phát triển hệ thống diagram) Sử dụng yêu cầu để hiểu về hệ thống sẽ phát Kỹ sư hệ thống • triển Máy trạng thái – FSM (Finite state machine) 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) 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 21 22 21 22 Ví dụ: mô tả biểu thức toán học bằng Đặc tả chức năng với DFD DFD • 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: b c a d 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
7. 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 • Ý nghĩa của các ký pháp sử dụng được xác định Sách Tên sách, tác giả Tên người mượn Kho sách bởi các định danh lựa chọn của NSD Sách • Tên tác giả Ví dụ: DFD của chức năng tìm kiếm sách: Có If NSD nhập vào cả tên tác giả và tiêu đề sách Then Danh sách tác giả sách Thông tin về sách tìm kiếm sách tương ứng, không có thì thông báo lỗi Tên sách Tên sách; Danh sách tên sách Tên người mượn Elseif chỉ nhập tên tác giả Then Danh sách người mượn hiển thị danh sách các sách tương ứng với 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 chủ đề liên quan đến chủ đề Elseif chỉ nhập tiêu đề sách Then Chủ đề . . . Chủ đề yêu cầu Đưa ra Tên sách Endif 25 26 25 26 Các hạn chế của DFD Các hạn chế của DFD • Trong DFD không xác định rõ các • Chức năng D có thể cần cả A, B và C • DFD không xác định sự đồng bộ giữa các chức hướng thực hiện (control aspects) • 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 A • Chức năng D có thể kết xuất kết – E quả cho một trong E và F A xử lý dữ liệu và B được hưởng (nhận) các kết 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
8. Đặ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 – 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ả • δ : Q x I à Q hay theo chủ đề Báo động áp lực cao – Tìm kiếm sách theo các yêu cầu của người mượn – Tìm kiếm sách quá hạn trả, . . . Báo động nhiệt độ cao ON OFF Khởi động lại 29 30 29 30 Đặc tả yêu cầu Đặc tả các đối tượng • Độ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 • Một số sách không được mượn về – Mã quyển – 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
9. Đặc tả dữ liệu với FSM đặc tả trạng thái Mô hình thực thể liên kết -ERD • Ta có tập hợp các sách (mỗi đầu sách có thể có 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 – (AV) Available: được phép mượn, • ER Model – (CO) - (BR): đã mượn (Check Out; Borrow), – Thực thể – (L): Last, CO AV BR – Quan hệ – (R): Remove – Thuộc tính • Biểu đồ thực thể L R 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 33 34 Thực thể Thuộc tính • Tính chất của một thực thể hoặc một đối • 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 • Thực thể có thể có mối quan hệ: – mô tả mẫu (instance) – 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
10. 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 Ø Cardinality : chỉ ra định lượng của mối quan hệ N N Title 1:1 one-to-one 1:N one-to-many M:N many-to-many state Ø Modality : 0 – có thể có, có thể không có quan hệ Was Text holds held Written by 1 – bắt buộc có quan hệ by 1 M 1 Is N Author Customer provided Repair Action Borrower with limit 37 38 37 38 So sánh Thế nào là một đặc tả tốt? DFD FSM ERD • 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 Mô tả trạng thái của thực • Mô tả luồng dữ liệu thể Mô tả trừu tượng cơ sở Có ít quy ước khi mô tả, có thể tạo đơn giản dữ liệu Xác định rõ hướng thực • 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: Thể hiện tốt tính song Không thể hiện tính tuần 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
11. 2.1 D Customer 1 Order Thế nào là một đặc tả tốt? Customer Verify Master Customer Need to establish Valid Khách hàng mới 2.2 D Inventory 2 Order Update Đặt hàng Mặt hàng Customer Verify Master Hệ thống Item Hoá đơn Phiếu hàng Kho hàng Notify Khách hàng đặt hàng 2.4 Thông báo Update chuyển hàng Valid Avail Commit 2.3 Item D Shipping 4 Check Taxes Available Tax 2.5 Back Ord D Inventory 2 Master Order Create D Back 3 Order Pending Order Order 41 42 41 42 4. Nguyên lý phân tích yêu cầu sử Mô hình hóa các chức năng dụng 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 • 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ế 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
12. 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 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 khác nhau 45 46 45 46 Bản chất của việc phân tích • 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 cài đặt 47 47