Thursday 10 February 2022

Intellectual property and standards specifications




1. the level of standards: international standards, national standards, industry standards, local standards, enterprise standards
2. type of standard: mandatory standard, recommended standard. there are 8 mandatory standards
3. the correspondence between national standards and international standards: equivalent adoption (idt), modified adoption (mod), equivalent adoption (eq), non-equivalent adoption (neq). non-equivalent adoption is not an international standard for adoption.
4. national standard code, mandatory national standard, recommended national standard,  national standardization guidance technical documents. the management departments.



5. basic standards of the software industry:


(1) software engineering terms, terms, the following 19 are commonly used:


acceptance criteria: the criteria for software products to meet at a certain test stage, or the criteria for software products to meet delivery requirements.

acceptance testing: determine whether a system meets its acceptance criteria so that customers can determine whether to receive formal testing of the system.

demand side: an institution that obtains or obtains a system, product or service from the supplier. the demand side can be buyers, customers, owners, users, purchasing personnel, etc.

activity: the constituent element of a process. changes to the baseline are subject to formal approval by the relevant authorities.

audit: an independent check to assess compliance with software requirements, specifications, baselines, standards, processes, directives, codes, and contracts and special requirements.

code audit: an independent review of source code by someone, a team, or with the help of a tool to verify compliance with software design documentation and programming standards. correctness and validity may also be estimated.

configuration audit: prove that all required configuration items have been generated and that the current configuration matches the specified requirements. the technical documentation specification completely and accurately describes the process by which each configuration item is made and all requests for changes that have been made have been resolved.

certification: a written guarantee that a system, component or computer program meets its prescribed requirements and is acceptable for operational use.

walk-through: a static analysis technique or review process in which a designer or programmer guides members of a development team through their own written designs or codes, while other members are responsible for asking questions and commenting on the technique, style, possible errors, whether they violate development standards, and so on.

qualification: a formal process by which it is determined whether a system or component meets its specifications and is suitable for operational use in the target environment.

l baseline: has been formally reviewed and approved and can be used as a basis for the next development. for configuration management, there are three types of baselines: a functional baseline (a feature configuration that was initially passed), an assignment baseline (the configuration of the assignment that was initially passed), and a product baseline (a product configuration that was initially passed or conditionally passed).

configuration control committee: the authority responsible for evaluating and approving changes to the proposed works, and ensuring the realization of changes to approvals.

configuration management: the process of identifying and determining configuration items in the system.

configuration status reporting: records and reports on the information needed to effectively manage a configuration.

design review: submission of the preliminary or detailed design of the system to the user, the customer play stakeholder for approval at a formal meeting: a formal assessment and review of existing or proposed designs, the purpose of which is to identify and remedy design defects that may affect the suitability and environment of the product, process or service, and/or to identify possible improvements in performance, safety and economics.

desktop check: manual simulation of program execution, using step-by-step inspection of the source code for logic or syntax errors to detect failures. (programmer self-check)

evaluation: the process of deciding whether a product, project, activity or service meets its prescribed guidelines.

faults, defects: functional parts cannot perform the required functions.

feature configuration audit: a review that verifies that the actual working performance of a configuration item meets its requirements specification to establish a baseline for software design and coding.

(2) file editing symbols and conventions for information processing, data flow chart, program flow chart, system flow chart, program network diagram and system resource map
(3) information processing system computer system configuration diagram symbols and conventions


6. Software life cycle management standards: 

 

information technology software life cycle process, including the main process, support process and organizational process, the following table describes its activities and tasks.


7. documentation standards:


(1) computer software documentation specifications, which stipulate the specific content of 25 kinds of documents, and users can tailor them appropriately according to the actual situation.


the following is how each phase of the software lifecycle relates to software documentation:

the following are the requirements for document control:


l for the development group engaged in a software development tool, a full-time document management personnel (interface management engineer or document administrator) should be set up; in the development group, the main text of all existing documents in the project should be kept in two sets. the contents of the two sets must be exactly the same, one of which is available for lending and the other which is absolutely not allowed to be lent, in case of ineffectuality.


every document submitted to the document manager must be signed by the author, reviewer and approve.


the staff in the development group may, according to the needs of the work, hold some documents, i.e. individual documents, during the development of the project, but such individual documents must be copies of the main text, which must be exactly consistent with the main text, and if they are to be modified, the main text must be modified first.


personal files owned by different developers are usually various subsets of the main text.


if a document has been replaced by another new document, the original document should be written off.


when the development of a project is nearing completion, the document manager shall take back the individual documents of each member of the development group one by one and examine the contents of these documents.


(2) computer software requirements specification specification (srs)


8. quality and test standards: 

 

information technology software product evaluation quality characteristics and their use guide. divided into 4 subsets, proposes a quality model in the software life cycle that can be evaluated by measuring internal properties (typically static measures of intermediate products), external properties (typically by measuring the behavior of code execution), or by measuring attributes that use mass. the goal is to make the product have the desired utility in the specified use environment, process quality helps to improve product quality, and product quality in turn helps to improve the quality of use. the quality model is shown in the following figure:

 

Defines 6 mass characteristics and 21 mass sub-characteristics that describe software quality with minimal overlap.

9. computer software reliability and maintainability management. 

 

it is used to guide the development and implementation of reliability and maintainability outlines over the lifetime of software products.

No comments:

Post a Comment