THIET KE VA XAY DUNG PHAN MEM
(SOFTWARE DESIGN AND CONSTRUCTION) Nam hoc 2008-2009
Giáo viên: PGS Huỳnh Quyết Thang BM Công nghệ phần mêm
Trang 2đ Chương I1 Tổng hợp và phân tích các yêu cầu phan mm
1 Cac van dé va khai niém trong yêu cầu phần mém
2 Phat hién cdc yéu cau phan mém (Software Elicitation)
3 Phân tích yêu cầu phân mêm và xây dựng các đặc tính xác định chất lượng yêu câu và các yêu câu khác
4 Đặc tả các yêu cầu phân mêm
5 Xác định nguôn gốc yêu cau và ma trận theo dõi các yêu
câu phan mêm
6 Thâm định xác mỉnh các yêu cau phan mém (verification requirement)
7 Quản lý thay đối yêu cau phan mém
Trang 3⁄1 3 Phân tích các yêu câu phần mêm và xây dựng các đặc SN tính xác định chât lượng yêu câu và các 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
Trang 4⁄1 3 Phân tích các yêu câu phần mêm và xây dựng các đặc tính xác định chât lượng yêu câu và các yêu câu khác
Trang 6
1.3 Phân tích các yêu cau phan mêm và xây dựng các đặc
tính xác định chât lượng yêu câu và các yêu câu khác
Functional software requirements
Trang 7
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc SN
tính xác định chật lương yêu câu và các vê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
Trang 8
1.3 Phân tích các yêu cau phan mêm và xây dựng các đặc SN tính xác định chât lương yêu câu và các 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
Trang 9
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc SN
tính xác định chật lương yêu câu và các vê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
Trang 10
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc SN
tính xác định chật lương yêu câu và các vê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
Trang 11
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc SN
tính xác định chật lương yêu câu và các vê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
Trang 12
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc SN
tính xác định chật lương yêu câu và các vêu câu khác
(4) Requirements Negotiation
Another term commonly used for this sub-topic 1s ‘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
Trang 13
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc SN
tính xác định chật lương yêu câu và các vê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 1s 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
Trang 14
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc
tính xác định chât lương yêu câu và các 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 1s 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
¬
Trang 15
1.3 Phan tich cac yéu cau phan mêm và xây dựng các đặc SN tính xác định chật lượng yêu câu và các yêu cầu khác
Các đặc tính chất lượng đôi với người sử dụng:
Avallability (đáp ứng) Efficiency (hiệu quả)
Flexibility (mém déo)
Integrity (bao mat)
Interoperability (kha nang két hop véi hệ thông)
Realibility (tin cay)
Robustness (kha nang kiém soat các dữ liệu không
chinh xac)
Usability (dé st dung)
` 15 /
Trang 16
1.3 Phần tích các yêu câu phân mêm và xây dựng các đặc
tính xác định chật lương yêu câu và các vêu câu khác
Các đặc tính chất lượng đỗi với 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 bằng các thuộc tính chất lượng