THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM (SOFTWARE DESIGN AND CONSTRUCTION) Năm học 2008-2009 Giáo viên: PGS 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) Phân tích yêu cầu phần mềm 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) Quản lý thay đổi yêu cầu phần mềm 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác Requirements Analysis: Detect and resolve conflicts between requirements Discover the bounds of the software and how it must interact with its environment Elaborate system requirements to derive software requirements 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác Requirements Analysis (KPAs): Requirements Classification Conceptual Modeling Architectural Design and Requirements Allocation Requirements Negotiation 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (1) Requirements Classification 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác Functional software requirements • Functional requirements express how the system behaves These requirements are usually action oriented Nonfunctional software requirements: • Usability • Reliability • Performance • Supportability Design constraints: • Typically impose limitations on the design of the system or the processes we use to build a system 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (2) Conceptual Modeling The development of models of a real-world problem is key to software requirements analysis Their purpose is to aid in understanding the problem, rather than to initiate design of the solution Hence, conceptual models comprise models of entities from the problem domain configured to reflect their real-world relationships and dependencies Several kinds of models can be developed These include data and control flows, state models, event traces, user interactions, object models, data models, and many others 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (2) Conceptual Modeling Several kinds of models can be developed The factors that influence the choice of model include: • • • • The nature of the problem Some types of software demand that certain aspects be analyzed particularly rigorously The expertise of the software engineer It is often more productive to adopt a modeling notation or method with which the software engineer has experience The process requirements of the customer The availability of methods and tools 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (3) Architectural Design and Requirements Allocation At some point, the architecture of the solution must be derived Architectural design is the point at which the requirements process overlaps with software or systems design, and illustrates how impossible it is to cleanly decouple the two tasks In many cases, the software engineer acts as software architect because the process of analyzing and elaborating the requirements demands that the components that will be responsible for satisfying the requirements be identified This is requirements allocation–the assignment, to components, of the responsibility for satisfying requirements 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (3) Architectural Design and Requirements Allocation: Allocation is important to permit detailed analysis of requirements Hence, for example, once a set of requirements has been allocated to a component, the individual requirements can be further analyzed to discover further requirements on how the component needs to interact with other components in order to satisfy the allocated requirements In large projects, allocation stimulates a new round of analysis for each subsystem Iterating Requirements and Design Using Parent-Child Requirements to Increase Specificity 10 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (3) Architectural Design and Requirements Allocation: Architectural design is closely identified with conceptual modeling The mapping from real-world domain entities to software components is not always obvious, so architectural design is identified as a separate topic The requirements of notations and methods are broadly the same for both conceptual modeling and architectural design IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems, suggests a multiple-viewpoint approach to describing the architecture of systems and their software items 11 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (4) Requirements Negotiation Another term commonly used for this sub-topic is ‘conflict resolution’ This concerns resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and non-functional requirements, for example 12 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (4) Requirements Negotiation In most cases, it is unwise for the software engineer to make a unilateral decision, and so it becomes necessary to consult with the stakeholder (s) to reach a consensus on an appropriate trade-off It is often important for contractual reasons that such decisions be traceable back to the customer We have classified this as a software requirements analysis topic because problems emerge as the result of analysis However, a strong case can also be made for considering it a requirements validation topic 13 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác Using the Use Cases To support the design and coding activities, the use cases developed in the elicitation activities must be more fully elaborated Use cases are most appropriate when the system is rich in functionality and must support differing types of users Use cases are not as effective when applied to systems with few or no users and minimal interfaces, those with mostly nonfunctional requirements, and design constraints 14 1.3 Phân tích yêu cầu phần mềm 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ác đặc tính chất lượng người sử dụng: Availability (đáp ứng) Efficiency (hiệu quả) Flexibility (mềm dẻo) Integrity (bảo mật) Interoperability (khả kết hợp với hệ thống) Realibility (tin cậy) Robustness (khả kiểm soát liệu khơng xác) Usability (dễ sử dụng) 15 1.3 Phân tích yêu cầu phần mềm 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ác đặc tính chất lượng người phát triển: Maintainability (bảo dưỡng) Portability (hiệu quả) Reusability (mềm dẻo) Testability (bảo mật) Tổng hợp có 12 thuộc tính chất lượng Cần phải cân thuộc tính chất lượng 16 ...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) Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu. .. Requirements Negotiation 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác định chất lượng yêu cầu yêu cầu khác (1) Requirements Classification 1.3 Phân tích yêu cầu phần mềm xây dựng đặc tính xác... 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) Quản lý thay đổi yêu cầu phần