THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM (SOFTWARE DESIGN AND CONSTRUCTION) Năm học 2007-2008 Giáo viên: TS.Huỳnh Quyết Thắng BM Công nghệ phần mềm Khoa CNTT, ĐHBK HN Chương Tổng hợp phân tích yêu cầu phần mềm Các vấn đề khái niệm yêu cầu phần mềm Phát yêu cầu phần mềm (Software Elicitation) Xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác Đặc tả yêu cầu phần mềm Xác định nguồn gốc yêu cầu ma trận theo dõi yêu cầu phần mềm Thẩm định xác minh yêu cầu phần mềm (verification requirement) 1.2 Phát yêu cầu phần mềm (Software Elicitation) Phân tích tốn Xác định q trình phát triển yêu cầu phần mềm Xây dựng khả (vision) phạm vi (scope) phần mềm Xác định nhóm người sử dụng đặc tính họ đại diện tiêu biểu cho nhóm Phân tích xác định yêu cầu phần mềm dựa đại diện nhóm NSD Xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (non-functional requirement) 1.2.1 Phân tích tốn (vấn đề) [Dean Leffingwell] • Problem analysis is the process of understanding • • • real-world problems and user's needs and proposing solutions to meet those needs The goal of problem analysis is to gain a better understanding, before development begins, of the problem being solved To identify the root cause, or the problem behind the problem, ask the people directly involved Identifying the actors on the system is a key step in problem analysis 1.2.1 Phân tích tốn (vấn đề) [Dean Leffingwell] - The specific steps that must be taken in order to achieve the goal: • Gain agreement on the problem definition • Understand the root causes—the problem behind • • • the problem Identify the stakeholders and the users Define the solution system boundary Identify the constraints to be imposed on the solution 1.2.1 Phân tích tốn (vấn đề) Step 1: Gain Agreement on the Problem Definition • Simply write the problem down and see whether everyone agrees • The Problem Statement: Table 4-1 Problem statement format Element Description The problem of Describe the problem affects Identify stakeholders affected by the problem the result of which Describe the impact of this problem on stakeholders and business activity Benefits of Indicate the proposed solution and list a few key benefits 1.2.1 Phân tích tốn (vấn đề) Step 2: Understand the Root Causes—The Problem Behind the Problem • Your team can use a variety of techniques to gain an understanding of the real problem and its real causes One such technique is "root cause" analysis, which is a systematic way of uncovering the root, or underlying, cause of an identified problem or a symptom of a problem 1.2.1 Phân tích tốn (vấn đề) Step 3: Identify the Stakeholders and the Users • Who are the users of the system? • Who is the customer (economic buyer) for the system? • Who else will be affected by the outputs that the system produces? • Who will evaluate and bless the system when it is delivered and deployed? • Are there any other internal or external users of the system whose needs must be addressed? • Who will maintain the new system? • Is there anyone else? 1.2.1 Phân tích tốn (vấn đề) Step 4: Define the Solution System Boundary • Who will supply, use, or remove information from • • • • • the system? Who will operate the system? Who will perform any system maintenance? Where will the system be used? Where does the system get its information? What other external systems will interact with the system? 1.2.1 Phân tích tốn (vấn đề) Step 5: Identify the Constraints to Be Imposed on the Solution • Potential system constraints: Economic, Political, Technical, System, Environmental, Schedule and resources 10 1.2.4 Phân tích xác định yêu cầu phần mềm dựa đại diện nhóm NSD Phát yêu cầu phần mềm cơng việc phức tạp Đây cầu nối để giải tốn Đây cầu nối PTV NSD Đòi hỏi nhiều nỗ lực phẩm chất PTV Một kỹ thuật tiêu biểu để xác định phát yêu cầu sử dụng “Trường hợp sử dụng”- use-case 24 1.2.4 Phân tích xác định yêu cầu phần mềm dựa đại diện nhóm NSD Use-case: Thể tập hợp tương tác tác nhân (actor) hệ thống Actor (tác nhân): Trường hợp sử dụng: 25 1.2.4 Phân tích xác định yêu cầu phần mềm dựa đại diện nhóm NSD Draft Functional Verified Requirement Functional Requirement use-case workshops Use-Case Description Draft Test Case Draft Analysis Models Veryfied Analysis Model Common Understanding 26 1.2.4 Phân tích xác định yêu cầu phần mềm dựa đại diện nhóm NSD Các lỗi thường điểm nên tránh phát yêu cầu: (1) Có nhiêu use-case (2) Có use-case trùng lặp (3) Trong mơ hinh use-case xay dựng không phép dưa vào giao diện với NSD (4) Định nghĩa liệu use-case (5) Cố gắng gắn yêu cầu với use-case 27 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Interview Requirements Workshops Brainstorming and Idea Reduction Storyboarding Applying Use Cases Prototyping 28 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Interview Interviewing is a simple and direct technique Context-free questions can help achieve bias-free interviews Then, it may be appropriate to search for undiscovered requirements by exploring solutions Convergence on some common needs will initiate a "requirements repository" for use during the project A questionnaire is no substitute for an interview 29 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Interview The Context-Free Question Who is the user? Who is the customer? Are their needs different? Where else can a solution to this problem be found? 30 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Interview Prepare an appropriate context-free interview, and jot it down in a notebook for reference during the interview Review the questions just prior to the interview Before the interview, research the background of the stakeholder and the company to be interviewed Don't bore the person being interviewed with questions you could have answered in advance On the other hand, it wouldn't hurt to briefly verify the answers with the interviewee Jot down answers in your notebook during the interview (Don't attempt to capture the data electronically at this time!) Refer to the template during the interview to make certain that the right questions are being asked 31 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Requirement Workshop The requirements workshop is perhaps the most powerful technique for eliciting requirements It gathers all key stakeholders together for a short but intensely focused period The use of an outside facilitator experienced in requirements management can help ensure the success of the workshop Brainstorming is the most important part of the workshop 32 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Requirement Workshop Preparing for the Workshop: • Selling the Concept • Ensuring the Participation of the Right Stakeholders • Logistics • "Warm-Up Materials" Role of the Facilitator Setting the Agenda Running the Workshop 33 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Brainstorming and Idea Reduction Brainstorming involves both idea generation and idea reduction The most creative, innovative ideas often result from combining multiple, seemingly unrelated ideas Various voting techniques may be used to prioritize the idea created Although live brainstorming is preferred, Web-based brainstorming may be a viable alternative in some situations 34 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Storyboarding The purpose of storyboarding is to elicit early "Yes, But" reactions Storyboards can be passive, active, or interactive Storyboards identify the players, explain what happens to them, and describe how it happens Make the storyboard sketchy, easy to modify, and unshippable Storyboard early and often on every project with new or innovative content 35 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Storyboarding Types of Storyboards Passive storyboards tell a story to the user They can consist of sketches, pictures, screen shots, PowerPoint presentations, or sample outputs Active storyboards try to make the user see "a movie that hasn't been produced yet." Active storyboards are animated or automated, perhaps by an automatically sequencing slide presentation or an animation tool or even a movie Interactive storyboards let the user experience the system in as realistic a manner as practical They require participation by the user in order to execute Interactive storyboards can be simulations or mock-ups or can be advanced to the point of throwaway code 36 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Applying Use Cases Use cases, like storyboards, identify the who, what, and how of system behavior Use cases describe the interactions between a user and a system, focusing on what the system "does" for the user The use-case model describes the totality of the system's functional behavior 37 1.2.5 Các kỹ thuật phát yêu cầu phần mềm từ phía khách hàng Prototyping Prototyping is especially effective in addressing the "Yes, But" and "Undiscovered Ruins" syndromes A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements Prototype the "fuzzy" requirements: those that, although known or implied, are poorly defined and poorly understood 38 .. .Chương Tổng hợp phân tích yêu cầu phần mềm Các vấn đề khái niệm yêu cầu phần mềm Phát yêu cầu phần mềm (Software Elicitation) Xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác... hình phân tích phần mềm Các thơng tin cho yêu cầu, trọng số yêu cầu Các bước tiến hành phá yêu cầu, phân tích yêu cầu 11 1.2.2 Xây dựng khả (vision) phạm vi (scope) phần mềm Khả phạm vi phần mềm. .. yêu cầu phần mềm Xác định nguồn gốc yêu cầu ma trận theo dõi yêu cầu phần mềm Thẩm định xác minh yêu cầu phần mềm (verification requirement) 1.2 Phát yêu cầu phần mềm (Software Elicitation) Phân