| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/Z 31102-2014 | English | RFQ |
ASK
|
3 days [Need to translate]
|
Software engineering -- Guide to the software engineering body of knowledge (SWEBOK)
| Valid |
GB/Z 31102-2014
|
PDF similar to GBZ31102-2014
Basic data | Standard ID | GB/Z 31102-2014 (GB/Z31102-2014) | | Description (Translated English) | Software engineering -- Guide to the software engineering body of knowledge (SWEBOK) | | Sector / Industry | National Standard | | Classification of Chinese Standard | L77 | | Classification of International Standard | 35.080 | | Word Count Estimation | 197,132 | | Date of Issue | 9/3/2014 | | Date of Implementation | 2/1/2015 | | Adopted Standard | ISO/IEC TR 19759-2005, MOD | | Regulation (derived from) | People's Republic of China Announcement of Newly Approved National Standards No. 21 of 2014 | | Issuing agency(ies) | National Health and Family Planning Commission | | Summary | This Standard specifies the bounds of software engineering disciplines, by topic provides a way to access the support of the discipline of literature. Develop software engineering knowledge (SWEBOK) Guide has the following five objectives: a) to promote t | GBZ31102-2014: Software engineering -- Guide to the software engineering body of knowledge (SWEBOK)
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Software engineering.Guide to the software engineering body of knowledge (SWEBOK)
ICS 35.080
L77
People's Republic of China national standardization of technical guidance documents
Software Engineering Software Engineering Knowledge System Guide
(SWEBOK)
(ISO /IEC TR19759.2005, MOD)
2014-09-03 released
2015-02-01 implementation
General Administration of Quality Supervision, Inspection and Quarantine of People's Republic of China
China National Standardization Administration released
Directory
Foreword V.
Introduction Ⅵ
1 Scope 1
2 software requirements
2.1 Overview 1
2.2 Software Requirements Basics 2
2.3 Demand Process 3
2.4 Demand leads 4
2.5 Requirements Analysis 6
2.6 Requirements Specification 8
2.7 Confirmation of Requirements 9
2.8 Practical Considerations 10
2.9 Topic and Reference Table 11
2.10 Recommended References for Software Requirements 13
2.11 Further Reading References 13
2.12 Related Standards
3 software design 19
3.1 Overview 19
3.2 Software Design Basics
3.3 software design of the key issues 21
3.4 software architecture and architecture 22
3.5 software design quality analysis and evaluation 23
3.6 Software Design Note 24
3.7 software design strategies and methods 25
3.8 Topic and Reference Table 26
3.9 Recommended References for Software Design 31
3.10 Further Reading References 32
3.11 related standards 33
4 software construction 33
4.1 Overview 33
4.2 Software Construction Basis 34
4.3 Construction Management 35
4.4 Practical Considerations
4.5 Topic and Reference Table 39
4.6 Recommended References for Software Construction 40
4.7 Further Reading References 40
4.8 related standards 40
5 software testing 41
5.1 Overview 41
5.2 Software Testing Basics 42
5.3 Test Level 44
5.4 Test Techniques 47
5.5 test-related measures 50
5.6 Test Process 52
5.7 Topic and Reference Comparison Table 54
5.8 Recommended References for Software Testing 58
5.9 Further Readings 58
5.10 Related Standards
6 software maintenance 60
6.1 Overview
6.2 Software Maintenance Basics
6.3 Software Maintenance Key Issues 63
6.4 Maintenance Procedures 67
6.5 Maintenance Technology 70
6.6 Topic and Reference Table 70
6.7 Recommended References for Software Maintenance 75
6.8 Further Reading References 76
6.9 Relevant standards 78
7 Software Configuration Management 78
7.1 Overview 78
7.2 SCM Process Management 80
7.3 Software Configuration Identification 84
7.4 Software Configuration Control 86
7.5 Software Configuration Status Descriptions 88
7.6 Software Configuration Review 88
7.7 Software Release Management and Delivery 89
7.8 Topic and Reference Cross-Reference 90
7.9 Recommended References for Software Configuration Management 92
7.10 Further reading references 92
7.11 Related Standards
Software Engineering Management
8.1 Overview 93
8.2 Initiation and definition of scope 95
8.3 Software Project Planning 96
8.4 Software Project Implementation 98
8.5 Review and Evaluation 99
8.6 closed 99
8.7 Software Engineering Measurement 100
8.8 Topic and Reference Cross-Reference 101
8.9 Recommended References for Software Engineering Management 103
8.10 Further Reading References 103
8.11 Related Standards 107
Software Engineering Process
9.1 Overview 107
9.2 Process Implementation and Change 108
9.3 Process Definition 110
9.4 Process Evaluation 111
9.5 Process and Product Measurements 112
9.6 Topic and Reference Cross-Reference 115
9.7 References to Software Engineering Processes 119
9.8 Further Reading References 120
9.9 Related Standards 123
Software Engineering Tools and Methods
10.1 Overview 124
10.2 Software Engineering Tools 126
10.3 Software Engineering Methods 128
10.4 Topic and Reference Cross-reference 129
10.5 Recommended References for Software Engineering Tools and Methods 130
10.6 Further Reading References 131
10.7 Related Standards 132
11 Software Quality 132
11.1 General 132
11.2 Software Quality Basics
11.3 Software Quality Management Process 135
11.4 Practical Considerations 138
11.5 Topic and Reference Cross-Reference 142
11.6 Recommended References to Software Quality 143
11.7 Further Reading References 145
11.8 Related Standards
Software Engineering Related Subjects
12.1 Guide 147
12.2 Computer Engineering 148
12.3 Computer Science 149
12.4 Management 149
Maths 149
Project Management
12.7 Quality Management 150
12.8 Software Ergonomics 150
System Engineering
Appendix A (Informative) IEEE and ISO Software Engineering Standard Assignment of SWEBOK Knowledge Domain 153
Appendix B (Informative) Thematic Classification According to Bloom's Taxonomy 161
Appendix C (informative) The structural changes of the guidance of technical documents compared with ISO /IEC TR19759.2005 172
Foreword
This instructional document has been drafted in accordance with the rules given in GB/T 1.1-2009.
The guidance of technical documents using the redrafted law revision using ISO /IEC TR19759.2005 "software engineering software engineering knowledge
System Guide. "
The structural differences between this Guidance Document and ISO /IEC TR19759.2005 are given in Appendix C.
This Guidance Document is proposed and managed by the National Technical Committee for Information Technology Standardization (SAC/TC28).
The guiding technical documents drafting unit. Guangxi up to translation business services limited liability company, China Electronics Standardization Institute, China
Academy of Sciences Institute of Automation, Shanghai Baosight Software Co., Ltd.
The main drafters of this guidance document are Wen Jiakai, Zhang Zuoyuan, Wang Li, Deng Zixian, Liu Lianfang, Shi Guiji, Ding Jinchun, Lu Dixi,
Cong group, Teng Yilong, Wei Hanmei, Zongcheng Qing, Zhou Yu.
Introduction
This guide has a wide range of readers of technical papers. The main target is the need to achieve the following aspects of software engineering consensus
Determine the education and training needs, job classification, the development of performance evaluation guidelines, the provisions of the software development tasks. Also oriented to practice (or tube
Software engineers and public officials responsible for developing public licensing policies and career guides. In addition, the following personnel will also be from this guideline
Benefit from the technical documentation Associations and teachers who define certification guidelines, conformity assessment guidelines, and career practice guidelines for university curricula, learning software workers
Students, teachers and trainers who develop curriculum and course content.
This Guidance Document divides the content of Software Engineering into 10 Knowledge Domains (KAs). Chapter 2 ~ Chapter 11 corresponds to this
10 knowledge domains. When establishing a discipline boundary, it is important to determine what disciplines the software engineering is to share with each other and with the public. to this end,
The guidance document also identifies eight related disciplines (see Chapter 12, "Software Engineering Related Subjects").
This guideline technical document adopts the decomposition structure, decomposes the knowledge domain into several sub-domains, and sub-domains are divided into several topics. This is for the reader to find
The topics of interest provide an appropriate avenue.
Figure 1 is a software engineering knowledge system guide knowledge domain decomposition diagram.
Book book
Software requirements, software design, software architecture, software testing, software maintenance of these five knowledge domains in accordance with the traditional waterfall life cycle order
The description, however, does not imply that this guideline document incorporates or encourages a waterfall model or any other model. Software Configuration Management, Software
Project management, software engineering process, software engineering tools and methods, software quality of these five knowledge domains described in alphabetical order.
This guidance document includes various references for each domain, including book chapters, designated essays, or other accredited authoritative letters
Interest source. The description of each knowledge domain also includes a reference table with the listed topics.
Knowledge domain description structure
The structure of knowledge domain description is as follows.
The introduction proposes a concise definition of knowledge domain and outlines the scope of the knowledge domain and its relationship with other knowledge domains. Theme decomposition structure
Has become the core of knowledge domain description, knowledge domain decomposition into subdomains, themes and subtopics. Brief description of each theme or sub-theme, with attached
Have one or more than one reference.
The choice of reference is mainly due to the fact that it constitutes the best presentation of the subject-related knowledge, taking into account the constraints of selecting the exam.
Use the cross-tabulation to link the subject and the reference.
The last part of the knowledge domain description is a list of recommended references, including for those who want to know more about the topic of knowledge domain
Read the suggestions further and list a list of the criteria most relevant to the domain of knowledge. Note that the quotation in square brackets "[]" in the body is pushed
Referrals, references in parentheses "()" are commonly used references for writing and supporting the text.
Software Requirements Knowledge Domain (see Figure 1, column a)
Software requirements are the properties that should be revealed to solve a real problem.
The first knowledge subdomain is "Software Requirements Fundamentals." Including the software requirements themselves as well as the major types of requirements (product and process
Functional, non-functional, and emergent nature). This subdomain also describes the importance of quantifiable requirements, and of system requirements and softness
Distinguish between pieces of demand.
The second knowledge subdomain is the "requirements process" that introduces the process itself, which faces the remaining five sub-domains and indicates how the requirements process relates to it
His software engineering process convergence. This subdomain describes the process model, process participants, process support and management, and process quality and improvement.
The third domain of knowledge is "demand leads," focusing on where software needs come from and how software engineers collect those needs. This child
Domain includes sources of demand and lead-out technologies.
The fourth knowledge sub-area "needs analysis" focuses on analyzing the needs of the process, so.
--- Detect and solve the conflict between needs;
--- Discover the boundaries of software and how the software interacts with its environment as necessary;
--- Detailed system requirements for software requirements.
Requirements analysis includes requirements classification, conceptual modeling, architecture design and requirements allocation and requirements negotiation.
The fifth subfield of knowledge is "Requirements Specification," which usually refers to the documentation or equivalent electronic version that systematically reviews, assesses, and
Approved. For complex systems, especially those involving a large number of non-software components, as many as three different types of documents are generated, including system definitions
Documentation, System Requirements Specification and Software Requirements Specification. This subdomain describes these three categories of documents and basic activities.
The sixth knowledge sub-area is "Requirement Acknowledgment", which aims to identify all the problems before submitting the resources to handle the requirements. Demand confirmation involved
And the process of examining the requirements document to ensure that these requirements define the correct system (ie, the system the user is looking for). This subfield is described separately
Under the theme. Demand review, prototyping, model validation and acceptance testing.
The seventh sub-area of knowledge is "practical considerations," describing topics that need to be understood in practice. The first topic is the iteration of the requirements process
quality. The next three topics are mainly concerned with change management and the need to maintain accurate reflection of the state of software under construction or the state of the software being built
Do not include change management, requirements attributes, and requirements tracking. The last topic is demand measurement.
Software Design Knowledge Domain (see Figure 1, column b)
According to the IEEE definition [IEEE610.12-90], software design is "a system or component that defines the architecture, components, interfaces and their
His characteristic process "and" the result of this process. "The domain of knowledge is divided into six sub-domains.
The first sub-domain proposed "software design basis", forming a preliminary understanding of the role and scope of software design, that is, the concept of generalized design, soft
Design context, software design process and enabling technology.
The second sub-domain groups "the key issues in software design." These issues include concurrency, event control and processing, and component parts
With error and exception handling and fault tolerance, interaction and presentation and data persistence.
The third subdomain is "Software Architecture and Architecture," with topics of overall structure and perspective, architectural style, design patterns, and finally
Program family and framework family.
The fourth sub-domain describes "software design quality analysis and evaluation." Although the entire domain of knowledge focuses on software quality, this subdomain is proposed
The topics that are particularly relevant to software design are quality attributes, quality analysis and evaluation techniques, and measures.
The fifth sub-domain is "software design notation," is divided into structural description and behavioral description.
The sixth subdomain describes "Software Design Strategies and Methods." First, describe the common strategy, followed by the description of function-oriented (structured)
Design method, object-oriented design method, data structure centralized design method and component-based design (CBD) method.
Software Construction Knowledge Domain (see Figure 1, column c)
Software architecture refers to the use of coding, validation, unit testing, comprehensive testing, debugging, and create useful, meaningful software. This knowledge
The domain consists of three sub-domains.
The first subdomain is "Software Architecture Foundation." The first three topics are basic principles of construction, namely minimization of complexity, prediction of change and
Easy to verify construction. The final theme discusses the construction of the relevant standards.
The second subfield describes "Construction Management." The topics are various tectonic models, tectonic planning and tectonic surveys.
The third subfield describes "practical considerations." Its theme is to structure design, construction language, coding, construction testing, reuse, construction quality and
integrated.
Software testing (see Figure 1, column d)
Software testing refers to the dynamic verification of program behavior with limited test cases. Test cases from the usually unlimited execution domain,
Appropriate selection of desired behavior. Software testing has five sub-domains.
The first subdomain is a description of "Software Testing Fundamentals." The first test-related terminology, followed by the key to describe the test, and finally
Is to test the connection with other activities.
The second sub-field is "test level." The level is divided according to the test object and test purpose.
The third subdomain is "test technology." The first category is based on the tester's intuition and experience of technology. The second category includes. Based on specifications
Technology, code-based technology, fault-based technology, usage-based technology, and technology related to the nature of the application. The subdomain is also proposed as
How to choose and combine the right technology.
The fourth subdomain covers "test-related measures." These measures are divided into two categories, the evaluation of the program under test and the evaluation of the completed tests.
The last subdomain describes the "test process," including practical considerations and testing activities.
Software Maintenance (See Figure 1, column e)
Once the abnormal operation of the software is exposed, the operating environment changes immediately and new user needs emerge. Although the software life cycle
The maintenance phase begins with delivery but maintenance takes place earlier than this. Software maintenance knowledge domain is divided into four sub-domains.
The first subdomain proposes "Software Maintenance Fundamentals." Terminology, Nature of Maintenance, Necessity of Maintenance, Main Cost of Maintenance, Evolution of Software
And maintenance.
The second sub-domain brings together "the key issues in software maintenance." Including technical issues, management issues, maintenance cost estimates and software maintenance
measuring.
The third subdomain describes the "maintenance process." Its theme is a variety of maintenance processes and maintenance activities.
The fourth subdomain is "Maintenance Technology," which includes program understanding, refactoring, and reverse engineering.
Software Configuration Management (see Figure 1, column f)
Software Configuration Management (SCM) is designed to systematically control configuration changes and maintain configuration integrity throughout the life of the system
Tracking, and at different points in time identifies the software configuration of the discipline. This domain includes six subdomains.
The first subdomain is SCM process management. Topics covered include SCM organizational context, SCM process constraints and guidelines, SCM planning,
SCM program and SCM supervision.
The second sub-domain is "Software Configuration Identity," which includes identification schemes that identify controlled items, build controlled items and their versions,
Acquire and manage the controlled tools and technologies. The primary topics in this subdomain are the managed item ID and software library.
The third subdomain is "Software Configuration Control" and is the management of changes within the software life cycle. Three themes are requests for software changes,
Evaluation and approval, and software implementation changes, deviations and exemptions.
The fourth subfield is "Software Configuration Status Description." Topics are software configuration status information and software configuration status reports.
The fifth sub-domain is "Software Configuration Audit", which includes software functional configuration audit, software physical configuration audit and software baseline audit.
The last subdomain is "Software Release Management and Delivery" covering software builds and software release management.
Software Engineering Management (see Figure 1, column g)
Software engineering management knowledge domain management of software engineering and measurement. Although measurements are important for all domains, here
Is the subject of a measurement procedure. There are six sub-domains, the first five sub-domains covering software project management, the sixth sub-domain description software measurement
program.
The first sub-area is "Initial Kai and scope definition", including requirements determination and consultation, feasibility analysis and revision of requirements review process.
The second sub-domain is "Software Project Planning", which includes process planning, deliverables determination, workload, scheduling and cost estimation, resource allocation,
Risk Management, Quality Management and Program Management.
The third subdomain is "Software Project Implementation." Topics are planned, supplier contract management, measurement process, monitoring process, control
Cheng and report.
The fourth sub-domain is "review and appraisal". The topics include the definition of demand satisfaction, performance appraisal and evaluation.
The fifth sub-field describes "closed", including closing confirmation, closing activity.
The sixth subfield describes "Software Engineering Measurement" and more specifically the measurement program. In the "Software Engineering Process Knowledge Domain" in the product and over
Process measurement is described. Many other knowledge domains also describe their own knowledge domain-specific measurements. Topics in this subdomain include measurement promises
The establishment and maintenance of measurement process planning, measurement process implementation and measurement evaluation.
Software engineering process (see Figure 1, column h)
Software Engineering Process Knowledge Domain focuses on the definition, implementation, evaluation, measurement, management, alteration and improvement of the software engineering process itself. Four points
Subdomain.
The first subdomain proposes "Process Implementation and Change." Its theme is process infrastructure, software process management cycle, process implementation and change
Model and practical considerations.
The second subdomain relates to "process definition." Topics include software lifecycle models, software lifecycle processes, process definition notation, over
Process adaptation and automation.
The third sub-field is "Process Evaluation." Topics include process evaluation models, process evaluation methods.
The fourth subfield describes "Process and Product Measurement." Software engineering process covers general product measurement and general process measurem...
|