JGJ/T 90-1992 Technical Specification for Computer Software Engineering in Construction Field JGJ/T90-92
Some standard content:
Engineering construction standard full text information system
Industry standard of the People's Republic of China
Construction field
Technical code for computer software engineering inconstructon
JGJ/T90-92
1993Beijing
Engineering construction standard full text information system
W Engineering construction standard full text information system
Industry standard of the People's Republic of China
Construction field
Technical code for computer software engineering inconstructon
JGJ/T90-92
Editor: Information Center of Ministry of Construction
Approving department: Ministry of Construction of the People's Republic of China Implementation date: June 1, 1993
Engineering Construction Standards Full Text Information System
Engineering Construction Standards Full Text Information System
Notice on the Release of the Industry Standard "Technical Specifications for Computer Software Engineering in the Construction Field"
Jianbiao [1992] 862
According to the requirements of the Ministry of Construction (91) Jianbiao Zi No. 718 document, the "Technical Specifications for Computer Software Engineering in the Construction Field" edited by the Information Center of the Ministry of Construction has been reviewed and approved as a recommended industry standard, numbered JG/T1002-92, and will be implemented on June 1, 1993. This standard is under the unified management of the Standard and Norms Research Institute of the Ministry of Construction, and its specific interpretation work is the responsibility of the Information Center of the Ministry of Construction.
This standard is organized and published by the Standard and Norms Research Institute of the Ministry of Construction. Ministry of Construction of the People's Republic of China
December 2, 1992
Note: The number of this standard is adjusted from JG/T1002-92 to JGJ/T90-92. Engineering construction standard full-text information system
W.bzsoso.cO Engineering construction standard full-text information system
Computer software development
General provisions
Document preparation requirements
Programming format conventions
Computer software acceptance
5 Computer software maintenance.
Appendix A
Appendix B
Appendix C
Appendix D
Sample Software Development Form
Sample Software Acceptance Form
Sample Software Maintenance Form
Terms Used in This Specification
Additional Notes
Engineering Construction Standard Full Text Information System
:(13)
(45)
Engineering Construction Standard Full Text Information System
1 General Provisions
1.0.1 This specification is formulated to ensure that all aspects of computer software development, maintenance and acceptance in the construction field meet unified requirements, to ensure that concepts and formats are consistent in software production, and that documentation is complete and clear, so as to improve the quality and efficiency of software production, promote the engineering and commercialization of software, and form a software industry in the construction field as soon as possible. 2 This specification applies to the development, maintenance and acceptance of software in the construction field. 1.0.2
3 The development, maintenance and acceptance of computer software in the construction field shall comply with the provisions of the current relevant national standards in addition to the implementation of this regulation. Engineering Construction Standard Full Text Information System
Engineering Construction Standard Full Text Information System
2 Terminology
2.0.1 Software Life Cycle
The entire process of a software product from the formation of the concept, through development, use and continuous addition and revision until it is finally eliminated.
2.0.2 User
The unit or individual who uses the program for actual needs. 2.0.3 Software
Computer program and its related data and documents, including solidified programs. 2.0.4 Interface
The interface between two different systems. For example, the interface device of two hardware devices, the interface program of two program blocks, the storage area accessed by two or more programs, etc. The user interface is the interface between people and machines, also known as the user interface. 2.0.5 Module
A logically separable part of a program. 2.0.6 Confirmation
At the end of each stage of the software development process, the results are evaluated to determine whether they are consistent with the original requirements. 2.0.7 Software Strength Test
Test the software within the system design capability, under critical conditions, and beyond the design scope within a predetermined period of time. 2.0.8 Task Undertaking Unit
The unit that develops, purchases or selects software products for the task entrusting unit. 2.0.9 Task Entrusting Unit
The unit that provides funds for product development and determines product requirements. 2.0.10 Correctness Maintenance
Engineering Construction Standard Full-text Information System
W Engineering Construction Standard Full-text Information System
Modifications made to correct software errors generated during the development phase but not discovered during the testing phase, including corrections to program errors, file errors, and design errors. 2.0.11 Adaptive maintenance
Software modifications to adapt to changes in the operating environment. 2.0.12 Perfection maintenance
Modifications and additions to expand functions or improve performance. 2.0.13 Maintenance administrator
Person responsible for organizing, managing and coordinating maintenance work. 2.0.14 Software maintainer
Staff who specifically completes software modifications. Working files
Various charts filled in during software development. Product files
Technical data or technical management data compiled during software development. Engineering Construction Standard Full-text Information System
Engineering Construction Standard Full-text Information System
Computer software development
3.1 General provisions
The computer software development process can be divided into seven stages: feasibility study and planning requirements analysis, outline design, detailed design, implementation, assembly test, and confirmation test. 3.1.2 The tasks, implementation steps and requirements of each stage of the computer software development process shall comply with the provisions of the current national standard "Computer Software Development Specifications". 3.1.3 The documents to be delivered at each stage of the computer software development process shall comply with the provisions of Table 3.1.3.
Documents to be delivered during the software development phase
Software development process
Name of each phase
Feasibility study and plan
Requirement analysis
Outline design
Detailed design
Assembly test
Confirmation test
3.2.1 Types of documents
Feasibility study report, project development plan (draft) Table 3.1.3
Software requirements specification, project development plan (revised draft), user manual Summary
Outline design specification
Detailed design specification, assembly test plan User manual
Assembly test report, list of executable programs Confirmation test report, final user manual, project development summary report
Document preparation requirements
Documents for computer software development should be divided into product files and work files. Engineering Construction Standard Full Text Information System
W Engineering Construction Standard Full Text Information System
2 Product Documents
3.2.2.1 Product documents shall include the following contents: (1) Feasibility study report;
(2) Project development plan;
(3) Software requirements specification;
(4) Outline design specification;
(5) Detailed design specification;
(6) User manual;
(7) Test plan;
(8) Test report;
(9) Project development summary report.
The content requirements of product documents shall comply with the provisions of the current national standard "Guidelines for the Preparation of Computer Software Product Development Documents". 3.2.3 Working documents
Working documents shall be presented in a table form. 3.2.3.1
Form codes shall comply with the following provisions:
-Use two digits to indicate the form type in this phase-Use one letter to indicate the development phase
Wherein, X is as follows:
G-General form;
P-Project development planning phase;
0-General design phase;
D-Detailed design phase.
Forms used in work documents during the software development phase should comply with Table 3.2.33.2.3.3
Regulations.
Engineering Construction Standards Full-text Information System
Engineering Construction Standards Full-text Information System
Project Development Phase
Project Development Plan
Phase (PLAN)
Outline Design Phase
(OUTLINE)
Detailed Design Phase
(DETAIL)
Forms Used in Working Documents
Form Name
General Table
Current System Flowchart
Fee Analysis Report
Schedule Plan
Staff Training Plan
Software and Hardware Configuration Table| |tt||General table
Data flow chart
System flow chart
Function module structure diagram
Function module communication interface table
Data structure description (also applicable to input/
output data structure)
Input/output data format description
Standard code list
Input/output list
File (library) list
Function module list
General table
Program module structure diagram
Program module communication interface table
Program module design task book
Program and document Software (library) interaction diagram
Program flow chart and algorithm description
Program module list
Internal variable list
Software transfer instructions
Use table format
See Appendix A.1
See Appendix A.2
See Appendix A.3
Wide Appendix A.4
See Appendix A.5
See Appendix A.6
See Appendix A.1
See Appendix A.7
See Appendix A.8
See Appendix A.9
See Appendix A.10
See Appendix A11| |tt||See Appendix A.12
See Appendix A.13
See Appendix A.14
See Appendix A.15
See Appendix A.16
See Appendix A.1
See Appendix A.17
See Appendix A.18
See Appendix A.19
See Appendix A.20
See Appendix A.21
See Appendix A.22
See Appendix A.23
See Appendix A24
Note: For software with an asterisk after each chart in the working file, software of medium scale or below (including medium scale) can be omitted. 1 The graphic format of the working document shall comply with the provisions of the current national standard "Documentation Symbols and Conventions for Information Processing Data Flow Diagrams, Program Flow Diagrams, System Flow Diagrams, Program Network Diagrams and System Resource Diagrams". 3.2.4 Software Scale Classification and Corresponding Product Documentation Requirements 3.2.4.1 The scale of software should be divided into the following three levels: small-scale software - source program less than 5,000 lines or storage less than 1M; medium-scale software - source program between 5,000 and 30,000 lines or storage between 1 and 50M; large-scale software - source program more than 30,000 lines or storage more than 50M. 3.2.4.2 Product documents to be submitted for software of different scales shall comply with the provisions of Table 3.2.4.
Product files to be submitted for software of different scalesProduct file name
Feasibility study reportWww.bzxZ.net
Project development plan
Software requirements specification
Outline design specification
Detailed design specification
User manual
Test plan
Test report
Project development summary report
Small scale
Instructions
Medium scale
Feasibility study and
Development plan
Software requirements and outline
Design specification
Test and
Summary report
Note: Those with \ sign are required, and those without sign are not selected. 3.3
1 Meta-symbol
Programming format conventions
Large-scale
3.3.1.1 The symbol “→” is used as a shrinkage indicator (does not appear in the actual program text), indicating that the line is shrinked to the right relative to the upper line, the left end of the arrow is aligned with the left end of the upper line, and the right end of the arrow indicates the starting position of this line (the specific number of shrinkages can be selected at a time, which should be 2 to 5 spaces).
The symbol “［” is an optional symbol, indicating that the content enclosed is optional.
3.3.2 Basic conventions
Engineering Construction Standard Full-text Information System
W.bzsoso:cOn Engineering Construction Standard Full-text Information System
The length of a program unit (main program or subroutine, the same below) should not exceed four pages of printed paper (about 240 lines, including comment lines); all symbols should have obvious meanings and can be explained through comments when necessary.
3.3.3 The program structure should include the following: (1) Description body
(2) Explanation statements (or identifiers, parameter lists); (3) Program body.
3.3.4 The description body can be given in the form of comments, and it should be separated from the rest of the program by a line of "1" before and after. The description body should include the following information: (1) Program name and meaning description;
(2) Version number and completion date;
(3) Program function;
(4) Programmer's name and unit;
(5) [Modifier's name, unit and modification date; (6) Dependence on the environment,
(7) Input data (or parameter) description;
(8) Output data (or parameter) description;
(9) [Other issues that need to be explained].
3.3.5 The program should be annotated. The number of lines of comment statements should account for 1/51/3 of the total number of lines of the entire program statements. Comment lines should be written neatly and the left end of the comments should be aligned. 3.3.6 Other conventions
3.3.6.1 In the program, except for the "" enclosed in the string, the rest of the "," should be wrapped anywhere. After the line break, except for the ones that should be indented according to the format requirements, the rest should be aligned with the left end of the previous line.
3.3.6.2 When a logical line is too long, it should be wrapped. When wrapping a line, a word should not be split, and the continuation line should also be indented. If the expression is too long and needs to be wrapped, the continuation expression should be aligned with the left end of the previous line expression. 3.3.6.3 In all places in the program where spaces are used as separators, it is advisable to retain only one space (except for comments and "". In arithmetic operators ("+" and "+"), relationship operators, and engineering standard full-text information system
W.bzsoso.coI18
See Appendix A.19
See Appendix A.20
See Appendix A.21
See Appendix A.22
See Appendix A.23
See Appendix A.24
Note: For any diagram in the working document with an * after it, the software below medium scale (including medium scale) can be omitted. 1 The graphic format of the working document shall comply with the provisions of the current national standard "3.2.3.4
Documentation Symbols and Conventions for Information Processing Data Flow Diagrams, Program Flow Diagrams, System Flow Diagrams, Program Network Diagrams and System Resource Diagrams". 3.2.4 Software scale classification and corresponding product file requirements 3.2.4.1 The scale of software should be divided into the following three levels: small-scale software: source code less than 5,000 lines or storage less than 1M; medium-scale software: source code between 5,000 and 30,000 lines or storage between 1 and 50M; large-scale software: source code more than 30,000 lines or storage more than 50M. 3.2.4.2 The product files to be submitted for software of different scales should comply with the provisions of Table 3.2.4.
Product files to be submitted for software of different scalesProduct file name
Feasibility study report
Project development plan
Software requirements specification
Outline design specification
Detailed design specification
User manual
Test plan
Test report
Project development summary report
Small scale
Instructions
Medium scale
Feasibility study and
Development plan
Software requirements and outline
Design specification
Test and
Summary report
Note: Those with \ sign are required, and those without sign are not selected. 3.3
1 Meta-symbol
Programming format conventions
Large-scale
3.3.1.1 The symbol “→” is used as a shrinkage indicator (does not appear in the actual program text), indicating that the line is shrinked to the right relative to the upper line, the left end of the arrow is aligned with the left end of the upper line, and the right end of the arrow indicates the starting position of this line (the specific number of shrinkages can be selected at a time, which should be 2 to 5 spaces).
The symbol “［” is an optional symbol, indicating that the content enclosed is optional.
3.3.2 Basic conventions
Engineering Construction Standard Full-text Information System
W.bzsoso:cOn Engineering Construction Standard Full-text Information System
The length of a program unit (main program or subroutine, the same below) should not exceed four pages of printed paper (about 240 lines, including comment lines); all symbols should have obvious meanings and can be explained through comments when necessary.
3.3.3 The program structure should include the following: (1) Description body
(2) Explanation statements (or identifiers, parameter lists); (3) Program body.
3.3.4 The description body can be given in the form of comments, and it should be separated from the rest of the program by a line of "1" before and after. The description body should include the following information: (1) Program name and meaning description;
(2) Version number and completion date;
(3) Program function;
(4) Programmer's name and unit;
(5) [Modifier's name, unit and modification date; (6) Dependence on the environment,
(7) Input data (or parameter) description;
(8) Output data (or parameter) description;
(9) [Other issues that need to be explained].
3.3.5 The program should be annotated. The number of lines of comment statements should account for 1/51/3 of the total number of lines of the entire program statements. Comment lines should be written neatly and the left end of the comments should be aligned. 3.3.6 Other conventions
3.3.6.1 In the program, except for the "" enclosed in the string, the rest of the "," should be wrapped anywhere. After the line break, except for the ones that should be indented according to the format requirements, the rest should be aligned with the left end of the previous line.
3.3.6.2 When a logical line is too long, it should be wrapped. When wrapping a line, a word should not be split, and the continuation line should also be indented. If the expression is too long and needs to be wrapped, the continuation expression should be aligned with the left end of the previous line expression. 3.3.6.3 In all places in the program where spaces are used as separators, it is advisable to retain only one space (except for comments and "". In arithmetic operators ("+" and "+"), relationship operators, and engineering standard full-text information system
W.bzsoso.coI18
See Appendix A.19
See Appendix A.20
See Appendix A.21
See Appendix A.22
See Appendix A.23
See Appendix A.24
Note: For any diagram in the working document with an * after it, the software below medium scale (including medium scale) can be omitted. 1 The graphic format of the working document shall comply with the provisions of the current national standard "3.2.3.4
Documentation Symbols and Conventions for Information Processing Data Flow Diagrams, Program Flow Diagrams, System Flow Diagrams, Program Network Diagrams and System Resource Diagrams". 3.2.4 Software scale classification and corresponding product file requirements 3.2.4.1 The scale of software should be divided into the following three levels: small-scale software: source code less than 5,000 lines or storage less than 1M; medium-scale software: source code between 5,000 and 30,000 lines or storage between 1 and 50M; large-scale software: source code more than 30,000 lines or storage more than 50M. 3.2.4.2 The product files to be submitted for software of different scales should comply with the provisions of Table 3.2.4.
Product files to be submitted for software of different scalesProduct file name
Feasibility study report
Project development plan
Software requirements specification
Outline design specification
Detailed design specification
User manual
Test plan
Test report
Project development summary report
Small scale
Instructions
Medium scale
Feasibility study and
Development plan
Software requirements and outline
Design specification
Test and
Summary report
Note: Those with \ sign are required, and those without sign are not selected. 3.3
1 Meta-symbol
Programming format conventions
Large-scale
3.3.1.1 The symbol “→” is used as a shrinkage indicator (does not appear in the actual program text), indicating that the line is shrinked to the right relative to the upper line, the left end of the arrow is aligned with the left end of the upper line, and the right end of the arrow indicates the starting position of this line (the specific number of shrinkages can be selected at a time, which should be 2 to 5 spaces).
The symbol “［” is an optional symbol, indicating that the content enclosed is optional.
3.3.2 Basic conventions
Engineering Construction Standard Full-text Information System
W.bzsoso:cOn Engineering Construction Standard Full-text Information System
The length of a program unit (main program or subroutine, the same below) should not exceed four pages of printed paper (about 240 lines, including comment lines); all symbols should have obvious meanings and can be explained through comments when necessary.
3.3.3 The program structure should include the following: (1) Description body
(2) Explanation statements (or identifiers, parameter lists); (3) Program body.
3.3.4 The description body can be given in the form of comments, and it should be separated from the rest of the program by a line of "1" before and after. The description body should include the following information: (1) Program name and meaning description;
(2) Version number and completion date;
(3) Program function;
(4) Programmer's name and unit;
(5) [Modifier's name, unit and modification date; (6) Dependence on the environment,
(7) Input data (or parameter) description;
(8) Output data (or parameter) description;
(9) [Other issues that need to be explained].
3.3.5 The program should be annotated. The number of lines of comment statements should account for 1/51/3 of the total number of lines of the entire program statements. Comment lines should be written neatly and the left end of the comments should be aligned. 3.3.6 Other conventions
3.3.6.1 In the program, except for the "" enclosed in the string, the rest of the "," should be wrapped anywhere. After the line break, except for the ones that should be indented according to the format requirements, the rest should be aligned with the left end of the previous line.
3.3.6.2 When a logical line is too long, it should be wrapped. When wrapping a line, a word should not be split, and the continuation line should also be indented. If the expression is too long and needs to be wrapped, the continuation expression should be aligned with the left end of the previous line expression. 3.3.6.3 In all places in the program where spaces are used as separators, it is advisable to retain only one space (except for comments and "". In arithmetic operators ("+" and "+"), relationship operators, and engineering standard full-text information system
W.bzsoso.coI2 When a logical line is too long, it should be broken. When breaking a line, a word should not be split, and the continuation line should also be indented. If an expression is too long and needs to be broken, the continuation expression should be aligned with the left end of the previous expression. 3.3.6.3 In all places where spaces are used as separators in the program, only one space should be reserved (except for comments and "". In arithmetic operators ("+", "+", "+"), relational operators, etc., the following should be used:2 When a logical line is too long, it should be broken. When breaking a line, a word should not be split, and the continuation line should also be indented. If an expression is too long and needs to be broken, the continuation expression should be aligned with the left end of the previous expression. 3.3.6.3 In all places where spaces are used as separators in the program, only one space should be reserved (except for comments and "". In arithmetic operators ("+", "+", "+"), relational operators, etc., the following should be used:
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.