SJ 20778-2000 Software Development and Documentation

SJ 20778-2000 Software Development and Documentation SJ20778-2000 Standard download decompression password: www.bzxz.net

Military Standard of the Electronic Industry of the People's Republic of China FL0137
SJ 20778--2000
Software development and documentation
Software development and documentationLink
Program name
Program address
D:Niupengpeng
DGoogle Translate (Program control
Has. Status
Ready to open192.168.5.157:43244
1Scope
2Reference file
3Definition
4 General requirements
5 Detailed requirements
6 Detailed requirements for documentation
6.1 Software Development Plan (SDP)
6.2 Software Test Plan (STP)
Software Installation Plan (SIP)
Software Transfer Plan (STrP)
6.5 Operational Concept Description (OCD)
System/Subsystem Requirements Specification (SSS)6.6
Interface Requirements Specification (IRS)
6.8 System/Subsystem Design Specification tt||6.10 Software Requirements Specification (SRS)
6.11 Software Design Description (SDD)
6.12 Database Design Description (DBDD)
6.13 Software Test Description (STD)
6.14 Software Test Report (STR)
6.15 Software Product Specification (SRS)
6.16 Software Version Description (SVD)
6.17 Software User Manual (SUM) )
6.18 Software Input/Output Manual (SIOM)6.19 Software Center Operator Manual (SCOM)6.20 Computer Operation Manual (COM)
6.21 Computer Programming Manual (CPM)
6.22 Firmware Support Manual (FSM)
Appendix A Glossary of Abbreviations and Terms (Supplement)
Appendix B Explanation of the Use of Reusable Software Products in This Standard (Supplement)Appendix C Classification of Problem Reporting Types and Priorities (Supplement)Appendix D Software Product Evaluation Price (supplement)
Appendix E Optional Joint Management Review (reference) Appendix F Optional Management Indicators (reference) Appendix G Program Strategy, Tailoring and Phase Planning Guide (reference) Appendix H Guide for Ordering Deliverables (reference) 2
Appendix I Guide for Transitioning from DOD-STD-2167A and DOD-STD-7953A to This Standard (reference)…1499
People's Republic of China Electronic Industry Military Standard Software Development and Documentation
Software development and documentation1 Scope
1.1 Purpose
The purpose of this standard is to establish uniform requirements for military software development and documentation. 1.2 Scope of Application
This standard will be used in the following four areas:
1.2.1 Organization and Agreement
SJ20778—2000
This standard can be used by contractors, subcontractors engaged in software development, or internal government agencies. For the sake of uniformity, the term "acquirer" refers to the organization that requires such technical work, "developer" refers to the organization that performs such technical work, "contract" refers to the agreement between these organizations, "statement of work" (SOW) refers to the list of tasks to be completed by the developer, "contract data requirements list (CDRL)" refers to the list of software products that can be delivered, and "subcontractor" refers to the organization that is entrusted by the developer to complete the required part of the tasks. "Software development" is a general term that includes new software development, modification, reuse, reengineering, maintenance and all other activities that produce software products. 1.2.2 Contract-specific application
This standard is effective by reference in the contract. This standard can be applied to each software product and each type of software (regardless of the media on which it is stored) covered by the contract to the extent specified in the contract. Examples of software types include deliverables and non-deliverables, software designed to meet user needs and software used in engineering and test environments. The acquirer should specify the software type and apply this standard or tailor it appropriately for each type of software. If this standard is cited without such optional application statement, it will be considered to be adopted in its entirety for all deliverable software. Regarding software development environment requirements This standard also applies to the deliverable software development environment. Although this standard is written for computer software configuration items (CSCI), it can also be used for software that is not designated as CSCI, as long as the term "CSCI\ is appropriately interpreted. Software installed in firmware also complies with all the above provisions. This standard does not apply to hardware components in firmware.
1.2.3 Tailoring
This standard can be tailored for various types of software that refer to this standard and its data item descriptions. Although tailoring is the responsibility of the purchaser, the prospective or selected developer can make tailoring suggestions. Tailoring guidelines for this standard can be found in Appendices G and H. 1.2.4 Explanation of selected terms
The following terms have special interpretations when used in this standard. 1 Ministry of Information Industry of the People's Republic of China 2000-10-20 AAA_tA nh
1.2.4.1 System
SJ 20778--2000
a. "System" in this standard may refer to: (1) a hardware-software system (e.g. a radar system), for which this standard applies only to its software part; (2) a software system (e.g. a salary calculation system), for which this standard applies to its entire development work; b. If the system consists of several subsystems, all requirements of this standard related to the system also apply to these subsystems. If a contract is based on a combination of systems and subsystems, such as a composite project, then the requirements and descriptions of the system in this standard shall apply to the subsystems. The same applies to these alternatives and their descriptions. 1.2.4.2 Participation in system development
In clauses dealing with system-level activities, the word "participation" is interpreted as follows: If the software covered by this standard is part of a hardware-software system and this standard applies only to its software part, then "participation" means "taking part", as described in the software development plan. If the software (possibly together with its computer) constitutes a system, then "participation" means "responsible". 1.2.4.3 Development, definition, etc.
Generally, this standard uses "development", "definition" , "establishment" or "identification" are interpreted to include new development, modification, reuse, reengineering, maintenance or any other activity or combination of activities that can produce a software product. 1.2.4.4 Records
Generally, the requirements of this standard for "records" are interpreted as "recorded in a way that can be retrieved or consulted", and the results can take a variety of forms, including, but not limited to, handwritten records, hard copies or electronic documents, and materials recorded using computer-aided software engineering (CASE) tools and project management tools. t.3 Priority
When the requirements of this standard and other When conflicts arise between applicable standardized documents, the acquirer shall be responsible for resolving such conflicts. 2 Referenced documents
GB/T11457-1995 Software Engineering Terminology
3 Definitions
This standard adopts the following definitions. In addition to the following definitions, other definitions of terms are given in GB/T11457. Note: In addition to the definitions provided here, Chapter 1 gives the specific usage of the following terms in this standard: acquirer, contract, contract document requirements list, definition, development and developer, establishment, identification, participation, record, software development, task book, subcontractor, subsystem and system.
3.1 Acceptance
An activity of the acquirer's authorized representative through which the acquirer accepts ownership of part or all of the software product to perform the contract.
3.2 Acquirer
An organization that purchases software products for itself or for another organization. 3.3 Approval
A written document signed by the authorized representative of the purchaser to express satisfaction with the project plan, design or other aspects of the developer and may serve as the basis for the next stage of work. This approval does not relieve the developer of the responsibility to meet the contract requirements. 3.4 Architecture architecture
SJ 20778-2000
The organizational structure of a system or CSCI, indicating its components, the interfaces between these components and the operational concepts between them.
3.5 Associate developer An organization that is neither the lead contractor nor a subcontractor to the developer, but that performs development work on the same or a related system or project.
3.6 Behavioral design The design of the behavior of the entire system or CSCI from the user's point of view, with the goal of satisfying user requirements without considering the internal implementation of the system or CSCI. This design is different from architectural design, which identifies the internal components of the system or CSCI and provides a detailed design of these components. 3.7 Build
(1) A version of the software that satisfies a specific subset of the requirements to be satisfied by the complete software, (2) The time it takes to develop a version of the software that satisfies a specific subset of the requirements. NOTE: The relationship between the terms "build" and "release" depends on the developer; for example, a build can be implemented as several releases, a build can be released in parallel (e.g., at different locations), or they can be used synonymously.
3.8 Computer database computerdatabase See database.
3.9 Computer hardwarecomputerhardwareA device that receives and stores computer data, performs a series of systematic operations on computer data, or produces control outputs. Such devices can perform basic interpretation, calculation, communication, control, or other logical functions. 3.10 Computer programcomputerprogramA collection of computer instructions and data definitions that enable computer hardware to perform a calculation or control function. 3.11 Computer softwarecomputer softwareSee software.
3.12 Computer software configuration itemcomputer software configuration item (CSCI)A collection of software that meets the end-use function and is specified by the purchaser for separate configuration management. The CSCI should be selected as a compromise of the following factors: software function, size, host or target computer, developer, support concept, reuse plan, criticality, interface considerations, need for separate documentation and control, and other factors. 3.13 Configuration itemconfigurationitem
A collection of hardware, software, or both that meets the end-use function and is specified by the purchaser for separate configuration management.
3.14 Databasedatabase
A collection of related data stored in one or more computer files in a way that can be accessed by users or computer programs through a database management system. 3.15 Database management systemdatabase management system is a set of computer programs that provide the functions required to create, modify, use and maintain the integrity of a database.
SJ 20778--2000
3.16 DeliverablesoftwareproductdeliverablesoftwareproductThe software product that the contract requires to be delivered to the purchaser or other designated recipient. 3.17 Designdesign
The features/specifications selected by the developer for a system or CSCI in response to certain requirements. Some of these features match the requirements; some are refinements of the requirements, such as defining all error messages in response to the requirement to display error messages; some are related to implementation, such as deciding which software units and logic to use to meet the requirements.
3.18 Developerdeveloper
An organization that develops software products ("development" includes new software development, modification, reuse, reengineering, maintenance, or any other activity that produces a software product). The developer may be a contractor or a government agency. 3.19 Documentationdocument/documentationA set of materials that can be read by humans or machines and are generally permanent (regardless of the media on which they are recorded). 3.20 Evaluationevaluation
The process of determining whether a project or activity meets specified criteria. 3.21 Firmwarefirmware
A combination of a hardware device and computer instructions and/or computer data that reside on the hardware device in the form of read-only software.
3.22 Hardware Configuration Itemhardwareconfigurationitem (HWCI)A set of hardware that meets the end-use function and is specified by the acquirer for separate configuration management. 3.23 Independent verification and validation (IV&V) A systematic review of software products and activities by an organization that is not responsible for the development of the product or the activities being reviewed. IV&V is not within the scope of this standard. 3.24 Interface
In software development, a relationship between two or more entities (such as CSCI-CSCI, CSCI-HWCI, CSCI-user, or software unit). These entities share, provide, or exchange data based on this relationship. An interface is not a CSCI, software unit, or other system component; an interface is a relationship between these entities, not an implementation of the interface.
3.25 Joint review
An activity or meeting attended by representatives from both the acquirer and the developer to examine and discuss the status of the project, the software product, and/or problems in the project.
3.26 Non-deliverable software product Non-deliverable software product is not a software product that is required to be delivered to the acquirer or other specified recipient in the contract. 3.27 process
An organized set of activities performed to achieve a given purpose, e.g., software development process. 3.28 qualification testing qualification testing Testing performed to demonstrate to the acquirer that a CSCI or system meets its specified requirements. 3.29 reengineering
The process of inspecting and modifying an existing system in order to reorganize it in an incremental manner. Reengineering may include reverse engineering (analyzing a system and generating a higher level of abstraction to represent it, such as from code to design), refactoring (converting a system from one representation to another at the same level of abstraction), redocumentation (analyzing a system and generating user documentation or support documentation), forward engineering (generating a new system from an existing system's software product incorporating new requirements), retargeting (converting a system so that it can be installed on a different target system), and translation (converting source code from one language to another or from one version of a language to another).
3.30 Requirements
(1) The characteristics that a system or CSCI must possess in order for the acquirer to accept it. (2) Statements that must be followed as specified in this standard or in the contract.
3.31 Reusable software product A reusable software product is a software product that was developed for use but has other uses, or a software product that is developed specifically for use in multiple projects, or a software product that has multiple roles in a project. Examples include (but are not limited to) commercial software products on the market, software products that are already deployed by the acquirer, software products in a reuse library, and existing software products on the developer's side. Each use may include all or part of these software products, and may also involve modified parts of them. The term can be applied to any software product (such as requirements, architecture, etc.) and not just software itself. 3.32 Software software
Computer programs and computer databases.
Note: Although some definitions of software include documentation, this standard limits this definition to computer programs and computer databases. 3.33 Software development software development The set of activities that produce a software product. Software development may include new development, modification, reuse, reengineering, maintenance, or any other activity that produces a software product. 3.34 Software Development File (SDF) is a database related to the development of a specific software entity. Its contents generally include (directly or by reference) requirements analysis, design and implementation considerations, principles and constraints: internal testing data of the developer; progress and status data. 3.35 software development library software development library (SDL) A set of controlled software, documentation, other intermediate and final software products, and related tools and methods used to promote the orderly development and subsequent support of software. 3.36 software development process software development process An organized series of activities to transform user requirements into software products. 3.37 software engineering software engineering In general, it is a synonym for software development. In this standard, software engineering is a subset of all software development activities (except qualification testing). This standard makes this distinction only to give different names to software engineering and software testing environments.
3.38 software engineering environment software engineering environment Facilities, hardware, software, firmware, methods and documents required to implement software engineering. It can include (but is not limited to) computer-aided software engineering (CASE) tools, compilers, assemblers, linkers, loaders, operating systems, debuggers, simulators, emulators, documentation tools and database management systems. 9
SJ20778—2000
Software or corresponding data created, modified or combined to meet a contract. Examples include plans, requirements, designs, codes, databases, test data and manuals. 3.40 Software QualitysoftwarequalityWww.bzxZ.net
The ability of software to meet specified requirements. 3.41 Software Supportsoftwaresupport
A series of activities that occur to ensure that the software can continue to operate according to the established objectives after installation and can play the established role in the operation of the system. Software support includes software maintenance, user support and related activities. 3.42 Software Systemsoftwaresystem
A system composed only of software, and sometimes may also include the computer equipment on which the software depends for operation. 3.43 Software Test EnvironmentsoftwaretestenvironmentThe facilities, hardware, software, firmware, methods and documents required to complete software qualification testing and possible other tests. Elements may include (but are not limited to) simulators, code analyzers, test case generators, and path analyzers, and may include elements used in a software engineering context. 3.44 software transition software transition a set of activities that transfer responsibility for software development from one organization to another. Typically, the former organization performs initial software development and the latter performs software support. 3.45 software unit software unit
a basic unit in the CSCI design; for example, a major component of the CSCI, a component of such a component, a class, object, module, function, subroutine, or database. Software units may appear at different levels of the hierarchy and may be composed of other software units. There may or may not be a one-to-one correspondence between software units in the design and the code and data entities that implement them (subroutines, procedures, databases, data files, etc.), or between the computer files that contain these entities. 3.46 support (of software) support (of software) See software support.
3.47 transition (of software) transition (of software) See software transition.
4 General requirements
4.1 Software development process
The developer shall establish a software development process consistent with the contract requirements. The software development process shall include the following major activities, which may overlap and be applied repeatedly. Different activities may be used for different software components and do not have to be performed in the order listed below. The developer's software development process shall be described by a software development plan. a. Project planning and supervision (5.1);
b. Establish software development environment (5.2);
c. System requirements analysis (5.3);
d. System design (5.4);
e. Software requirements analysis (5.5);
f. Software design (5.6)
SJ 20778-2000
g. Software implementation and unit testing (5.7); h. Unit integration and testing (5.8);
i. CSCI qualification testing (5.9);
j. CSCI/HWCI integration and testing (5.10); k. System qualification testing (5.11);
1. Preparation for software use (5.12);
m. Preparation for software handover (5.13);
Integrated process:
n. Software configuration management (5.14);
0. Software product evaluation (5.15);
p. Software quality assurance (5.16);
q. Corrective actions (5.17);
r. Joint technical and management review (5.18); s. Other activities (5.19).
4.2 General requirements for software development
The developer shall meet the following general requirements when implementing the detailed requirements of Chapter 5 of this standard. 4.2.1 Software development methods
The developer shall adopt a systematic and documented approach to all software development activities. These methods shall be described or referenced in the software development plan. 4.2.2 Software product standards
The developer shall develop and apply various standards for describing requirements, design, coding, test cases, test processes and test results. These standards shall be described or referenced in the software development plan. 4.2.3 Reusable software products
The developer shall meet the following requirements:
4.2.3.1 Incorporation of reusable software products
The developer shall identify and evaluate reusable software products used to meet contract requirements. The scope of the investigation of the products and the criteria used for evaluation shall be consistent with those described in the software development plan. Reusable software products that meet the criteria should be actually used. Appendix B provides the required and optional criteria for the adoption of reusable software products and the interpretation of them in this standard. The adopted software products shall meet the requirements of the data rights specified in the contract.
4.2.3.2 Development of reusable software products
During the performance of the contract, the developer shall identify opportunities for the development of reusable software products and evaluate the benefits and costs of these opportunities. Opportunities that provide cost-benefit and consistency with the planned targets shall be indicated to the acquirer. Note: In addition, the contract may require the developer to develop some software products specifically for the purpose of reuse. 4.2.4 Handling of critical requirements
The developer shall meet the following requirements:
4.2.4.1 Safety assurance
SJ20778—2000
Failures may lead to dangerous system states (i.e. states that result in accidental death, injury, property damage or harm to the environment). If such software exists, the developer shall develop a safety assurance strategy. Includes testing and analysis to ensure that potential dangerous situations in the software requirements, design, implementation and operation processes are eliminated or minimized. This strategy should include a software security plan. And combine it with the system security plan (if one exists). The developer should record this strategy in the software development plan. Implement this strategy and provide evidence that this security assurance strategy has been implemented. This part of the work should be part of the required software product. 4.2.4.2 Confidentiality Assurance
The developer should identify some CSCIs or parts of them that are critical to confidentiality, whose failure may cause the violation of system confidentiality. If such software exists, the developer should develop a confidentiality assurance strategy to ensure that the possibility of violating system confidentiality caused by the requirements, design, implementation and operation of this software is minimized or eliminated. The developer should record this strategy in the software development plan. Implement this strategy and provide evidence that this confidentiality assurance strategy has been implemented. These works should be part of the required software product. 4.2.4.3 Privacy Assurance
The developer shall identify those CSCIs or parts thereof that are critical to privacy and whose failure could result in a violation of the privacy of the system. If such software exists, the developer shall develop a privacy assurance strategy to ensure that the possibility of violating the privacy of the system caused by the requirements, design, implementation, and operation of the software is minimized or eliminated. The developer shall record this strategy in the software development plan. Implement this strategy and provide evidence that the privacy assurance strategy has been implemented. These efforts shall be part of the required software product. 4.2.4.4 Assurance of Other Critical Requirements
If a system relies on software to meet requirements that are considered critical in the contract or system specifications, the developer shall identify those CSCIs or parts thereof whose failure could result in interference with the realization of these critical requirements. The developer shall develop a strategy to ensure that such interference caused by the requirements, design, implementation, and operation of the software is minimized or eliminated. The developer shall record this strategy in the software development plan. Implementing this strategy and providing evidence that the assurance strategy has been implemented shall be part of the required software product.
4.2.5 Utilization of Computer Hardware Resources
: The developer shall analyze the contract requirements for utilization of computer hardware resources (e.g., maximum utilization of processor power, main memory capacity, input/output device capacity, auxiliary device capacity, and communication/network device capacity). The developer shall allocate computer hardware resources among the CSCIs, monitor the utilization of these resources during the contract period, and identify or reallocate the need for additional resources as necessary to meet the contract requirements. 4.2.6 Documentation Principles
The developer shall document the principles that the assurance agency uses when making important decisions about the specification, design, implementation, and testing of the software. These principles shall include trade-offs, analysis methods, and decision criteria. These principles shall be documented in documents, code descriptions, or other media that will be transferred to the assurance agency. The meaning of "important decisions" and the method of providing these principles shall be described in the software development plan. 4.2.7 Facilitate the review of the purchaser
In order to review the software products and activities required by the contract, the developer shall provide the purchaser or its authorized representative with tijpg
5 Detailed requirements
SJ 20778—2000
The order of the requirements listed in this chapter does not mean that they must be performed in this order. Many activities can be carried out simultaneously; different software products can progress at different speeds; some activities described in the previous items may be related to the inputs from some activities given in the following items. If the software is developed in multiple development phases, some activities may be completed in each phase, while others may be completed only in some selected phases. These activities and software products cannot be completed before several or all phases are completed. Figure 1 provides an example of how each activity can be applied to one or more phases. The non-mandatory description in Chapter 5 will give an explanation of each activity for a project involving multiple development phases. A project with only a single phase will complete all required activities in that phase. Appendix G provides guidance on planning the development phases, determining what activities are included in each phase and how to arrange them.
Project Planning and Supervision
Establishing the Software Development Environment
System Requirements Analysis
System Design
Software Requirements Analysis
Software Design
Software Implementation and Unit Testing
Unit Integration and Testing
CSCI Qualification Testing
CSCI/HWCI Integration and Testing
System Qualification Testing
Preparing for Software Use
Preparing for Software Handover Preparation
Integrated process:
Software configuration management
Software product evaluation
Software quality assurance
Corrective activities
Joint technical and management review
Other activities
Phase 1
Phase 2
Phase 3
A correspondence between various activities and multiple development phasesProject planning and supervision
The developer shall plan and supervise the project in accordance with the following requirementsPhase 4
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.