What is software engineering standardization?

People's social life cannot be separated from communication. The first thing encountered and solved in communication is the communication tool - language and writing. After the advent of computers, the same is true of language. People need programming languages ​​to deal with computers. This language should not only be understood by computers, but also by others, making it a tool for interpersonal communication. The standardization of programming languages ​​was first put on the agenda. In the 1960s, programming languages ​​flourished and a large number of languages ​​appeared, which undoubtedly played an important role in promoting the development of computer languages. But it also brought a lot of trouble. Even the same language, due to different degrees of modification and changes when implemented on different models of computers, formed various "dialects" of this language, which set up obstacles for communication in writing programs. Formulating standardized programming languages ​​and specifying several standard subsets for a certain programming language has brought great convenience to both language implementers and users.

With the development of software engineering, people's understanding of computer software has gradually deepened. The scope of software work has expanded from just using programming languages ​​to write programs to the entire software life cycle. For example, the formation of software concepts, demand analysis, design, implementation, testing, manufacturing, installation and inspection, operation and maintenance until the software is retired (replaced by new software). At the same time, there are many technical management tasks (such as process management, product management, resource management) and confirmation and verification work (such as review and audit, product analysis, testing, etc.) that are often specialized work across various stages of the software life cycle. All these aspects should gradually establish standards or specifications.

On the other hand, the types of software engineering standards are also multifaceted. They may include process standards (such as methods, techniques, metrics, etc.), product standards (such as requirements, designs, components, descriptions, plans, reports, etc.), professional standards (such as job titles, codes of ethics, certifications, charters, courses, etc.), and notation standards (such as terminology, representation, language, etc.).

Taking the above two aspects into consideration, the standards of software engineering can be expressed in a two-dimensional table. Table 9.1 (a) and (b) give the general format of this two-dimensional table. Table (b) is a continuation of table (a). The table is filled with three examples of standards (please note their positions in the table):

①FIPSl05 is the "Guideline for Software Documentation Management" issued by the National Bureau of Standards (National Bureau of Standards, Guideline for Software Documentation Management, FIPS PUB 105, June 1984)

②NSAC-39 is the "Verification and Validation for Safety Parameter Display Systems" issued by the Nuclear Safety Analysis Center of the United States (Nuclear Safety Analysis Center, Verification and Validation for Safety Parameter Display Systems, NSAC-39, December 1981).

③ISO 5807 is the "Information Processing - Documentation Symbols and Conventions for Data Flowcharts, Program Flowcharts, System Flowcharts, Program Network Diagrams and System Resource Diagrams" published by the International Organization for Standardization (now a national standard in my country) (the standard program flow chart discussed in Section 4.1 of Chapter 4 of this book is based on this). This table not only tells us the scope of software engineering standards and how to classify standards, but also guides the development of standards. The standards that have been formulated can find their corresponding positions in the table, and it can inspire us to formulate new standards.