Sample terms of reference for an information system. Description of the physical implementation of the database. Terms of reference for the creation of an information system
Technical specifications for design information system. Main sections terms of reference. Standards describing technical specifications. Analysis and development of requirements.
Technical task- a technical document (specification) that specifies a set of requirements for the system and is approved by both the customer/user and the contractor/manufacturer of the system. Such a specification may also contain system requirements and testing requirements.
The technical specifications contain the following sections:
General information. This section includes: the full name of the development, the full name and details of the customer and contractor, a list of documents that are the basis for the development, possible start and finish dates for work, the procedure for processing and presenting to the customer the results of work to create the system or its parts.
Reasons and purposes of development. The purpose of development refers to the type of automated activity processes.
System requirements. Contains subsections with requirements for the system as a whole and the functions performed by the system.
Composition and content of work to create the system. List of works and their contents that are expected to be performed within the framework of this project
Procedure for control and acceptance of the system. Contains the approximate dates of intermediate control and the approximate date of delivery to the customer.
Requirements for the composition and content of work to prepare the development object for putting the system into operation. Described preparatory work on commissioning of the system.
Documentation requirements. Contains a list and composition of system documentation.
Development sources. Contains a list of documentation and literature that will be used in developing the system.
There are three standards that describe the technical specifications for designing an IS: GOST 34.602-89, GOST 19.201-78, GOST 19.102-77.
Requirements development can be based on surveys, questionnaires, etc. In addition, requirements can be formed on the basis of brainstorming, observation of production activities, analysis of regulatory documentation, analysis of already created IS, analysis of versions of the IS used.
When developing requirements, problems of ambiguity, incompleteness, and inconsistency of individual requirements often arise. Fixing these problems during the requirements development stage costs several orders of magnitude less than fixing the same problems later in development.
User interface of information systems. General principles of construction. User interface styles. User interface effectiveness criteria. User interface design guidelines. Design rules.
User Interface– this is the software part of the information system, responsible for managing the devices with which the user communicates with the program.
User interface planning and design should be based on the following models:
- Mental model– some expectations of a person based on a sense of reality and on his knowledge and experience of working with a computer.
- Custom model- by observing how users work with a new interface and analyzing their feedback on the work, you can form general ideas about the future interface. It is important that the user is included in the work on the IS as early as possible.
- Programmer model– is born in the programmer’s head and is based on his professional activities.
User interface styles. There are four main user interface styles:
- Graphical user interface (Graphical User Interface, GUI) – this interface is based on four fundamental elements: windows, pointers (mouses), menus and icons. Other elements are also used: buttons, switches, input fields, etc. A feature of this interface is the advanced capabilities of screen design and control using the mouse pointer.
- Web-interface (Web User Interface, WUI) – the interface resembles the GUI interface, but was initially poorer than it. In particular, it used a single window mode and did not have the ability to “drag and drop” objects. With the development of JavaScript and Ajax, it becomes more like a GUI interface.
- InterfaceHUI (Human User Interface) is the user interface of handheld devices. Typically, such devices have a very small screen. It contains some GUI elements, such as menu items and icons.
- Object interface style. Object programming capabilities bring the nature of objects into the user interface. The object approach is characterized by such capabilities as dragging elements, context menu, tooltips, etc.
Consider a set of user interface quality criteria:
- Understanding users – to what extent user needs are reflected in the program interface.
- Efficiency in the design process– determines whether the product is carefully thought out and designed.
- Necessity of the project– whether the product has economic and social significance.
- Suitability for study and use– how difficult the product is to learn and use.
- Correspondence– whether the product design corresponds to solving the problems posed.
- Aesthetic feelings– how aesthetically pleasing the product is to use.
- Changeability– how much the design can be changed according to user requirements.
- Controllability– to what extent is the product controllability function implemented: installation management, training, support.
General principles for constructing a graphical interface:
Using a single user environment in the form of a so-called desktop;
Using graphic windows to display data;
Using non-keyboard input (using a mouse).
User interface design rules:
- User control - developers should give the user the most full control over the IP (as far as security allows). Let's consider several particular implementations of this principle:
1) reducing the memory load - the user’s memory is not so large and not so fast.
2) interface compatibility – the ability of users to transfer their experience and knowledge to work with new software.
Modeling information systems. The need for modeling languages. LanguageUML. Principles of object-oriented design. Language Diagrams OverviewUML. Use case diagrams and class diagrams.
Modeling– this is the replacement of the object under study (original) with its conventional image or another object (model) and the study of the properties of the original by studying the properties of the model.
The effectiveness of modeling can be achieved if two conditions are met: the model provides a correct display of the properties of the original; The model eliminates the problems inherent in taking measurements on a real object.
Modeling language – is a notation, primarily graphical, that is used to describe projects. Notation represents a collection of graphic objects used in the model. Notation is the syntax of a modeling language. The modeling language, on the one hand, should make the designer’s decisions understandable to the user, and on the other hand, provide designers with the means for the most formalized representation of the information system. Graphic representation is often the most clear form presentation of information.
UML (Unified Modeling Language– unified modeling language)- language graphic description for object modeling in development software.UML uses graphical notation to represent an abstract model of a system, called a UML model. This language was developed for modeling IS. UML is not a programming language, but code is generated based on the UML model.
Object-oriented model is a set of diagrams that describe, using the UML language, various aspects of the structure and behavior of the IS.
DiagramUML is a graphical representation of a set of elements, most often depicted as a graph with vertices (entities) and edges (relationships).
TECHNICAL TASK
for the development of an information system
1. General information
4. System requirements
6. Procedure for control and acceptance of the system
1. General information
In accordance with agreement No. MP23 between TechnoPlus LLC (hereinafter referred to as the Developer) and OptoTorgovlya LLC (hereinafter referred to as the Customer), the Developer designs the database, develops and puts into operation the “Accounting” information system trading operations»
The start date for the design of the BDB is considered to be the day following the signing of this Technical Specification
If during the development process the Customer changes the requirements described in this document, they are formalized a separate document and entail a change or addition to the Agreement between the Customer and the DB Developer regarding the deadline for completion and payment of the agreement
The Customer pays for the work of the Database Developer in accordance with Agreement No. XXX
2. Purpose and goals of creation (development) of the system
IS “Accounting for Trade Operations” is designed for storing, processing and analyzing information related to the Customer’s main activities.
The purpose of creating the IS “Accounting for Trade Operations” is:
Storing information about completed trading operations;
Reflection of trade transactions in accounting;
Analysis financial results trading operations;
Analysis of trading activities by product range and counterparties.
3. Characteristics of automation objects
3.1. The Customer's main activity is trade in furniture and related products by bank transfer.
3.2. The customer is not a VAT payer
3.3. During the day, the Customer makes no more than 100 trading transactions for the purchase and sale of goods.
3.4. The total volume of the product range does not exceed 3000 units
3.5. The total number of counterparties - suppliers is no more than 100 units.
3.6. The number of counterparties – buyers – is not limited. At the time of signing the contract N XXX was 300 units.
3.7. The Customer writes off goods from the warehouse using the weighted average cost method.
3.9. Only class 9 accounts are used as expense accounts.
3.10. The financial results of the trading activity of the enterprise (profitability and profitability of the operation) are calculated on the basis of the difference between sectors 702 and 902.
3.11. Trade transactions are recorded in the primary documents Receipt invoice, Expenditure invoice, Bank statement.
Pributkov's invoice (PN) will indicate the fact that the goods have arrived at the enterprise warehouse and include the following information:
- number;
– date;
– Name of the counterparty (company - postal owner);
– name of the product;
- strength;
– unit price of the product;
- sumu.
Vidatkov's invoice (VN) represents the fact that the goods have been promoted from the warehouse of the buyer and contains information similar to the information in PN (instead of the delivery company, the purchasing company is indicated).
Bank statement row confirms the fact of the receipt/vibration of funds from the rozrakhunku (r/r) enterprise and contains the following information:
– date;
– sign of arrival/payment of funds;
– Name of the counterparty (who was found / who was over-insuranced).
3.12. Skin primary document It is a platform for making regular entries that result in changes to existing accounting records. Trade transactions require the following transactions (Table 3.1)
Table 3.1 – Postings used in accounting at the Customer’s enterprise
Operation | Document | Account debit | Account credit | Posting amount |
Posting | Purchase Invoice | document amount |
||
Shipment of goods | Sales Invoice | document amount |
||
cost of goods shipped |
||||
Receipt of money to the current account | Bank statement (receipt) | document amount |
||
Transferring money from a current account | Bank statement (expenses) | document amount |
||
Determination of financial results | for the amount of closing 902 accounts |
|||
for the amount of closing 702 accounts |
de 281 – goods in stock;
311 – rozrahunkovy rakhunok in the vicious currency;
361 – retail stores with wicker purchases;
631 – rozrakhunki with postal workers;
702 – income from sales of goods;
902 – compatibility of goods sold (withdrawals).
3.13. The balance sheet of the synthetic form looks like that in Table 3.2.
Table 3.2 – Turnover balance of synthetic products
Item number | Cob balance | Turn over | Kintseve balance |
|||
Together |
4. System requirements
IS “Accounting for Trade Operations” must meet the following requirements:
4.1. The database for the IS “Accounting for Trade Operations” must provide storage, display and editing of reference and operational information.
Reference Information:
o description of goods:
Nomenclature (product) number;
Product Name;
Description;
o counterparties – suppliers;
Counterparty number;
Contractor's name;
Counterparty address;
Contacts;
o counterparties – buyers;
Counterparty number;
Contractor's name;
Counterparty address;
Contacts;
o chart of accounts on which accounting is carried out to record trading operations and analyze financial results;
o a list of basic transactions for displaying trading transactions in accounting caused by primary documents that have next view, as in table 3.1;
Operative information:
o Primary documents: Receipt invoice, Expenditure invoice, Bank statement (description of documents is given in 3.11)
o Accounting entries caused by primary documents (the type of entries is shown in table 3.2)
o Information about goods in stock:
Item Number;
Quantity;
Sum;
Average price.
4.2. The “Trade Operations Accounting” IS should allow you to automate the following actions:
4.2.1 Reflect the facts of receipt (receipt) and shipment of goods in the warehouse, namely, recalculate the quantity of goods in the warehouse and its average cost.
4.2.2 Generate accounting entries automatically based on primary documents.
4.2.3 Search for the following information:
Primary documents of the specified type for a certain period;
Postings for a specified document type for a specific date;
Information about the counterparty
Product information
4.2.4 Conduct an analysis of trading activity for the specified period in the following sections:
Financial results of trading activities;
Results of settlements for each counterparty;
Remaining goods in the warehouse for each item;
Transaction costs for each counterparty;
Cost and number of sales for each type of product
4.2.5 Generate reports for the specified period:
The equipment on which the IC is installed must be equipped with an uninterruptible power supply. In the event of a power outage, the IS should automatically shut down without losing data.
The IS must have backup mechanisms, and the IS must be equipped with appropriate hardware and software:
Quantitative values of reliability indicators:
- the automatic shutdown time should be no more than 1 minute;
- recovery time after a failure should be no more than 30 minutes;
- index fault tolerance The IS should be 11/7, i.e. uninterrupted operation of the IS 11 hours a day, 7 days a week.
Maintenance of the IS must be carried out without interrupting its operation.
4.5 Requirements for methods for assessing and monitoring reliability indicators at the stage of trial operation
To monitor reliability indicators at the stages of trial operation of the IS, maintenance personnel must maintain a Failure Log, which must contain the following information signs:
The date the error occurred;
The total operating time of the object from the beginning of its operation until the error was detected;
External signs and nature of the error;
The type of work in which the error was discovered.
4.6 IC performance requirements
The system must support the ability to process up to 1000 documents per day
The system must have the following performance:
80% of operations must have a response time (operation execution time) of less than 1 second;
15% of operations – from 5 seconds. up to 10 sec;
5% of operations - more than 10 seconds, but not more than 30 minutes.
4.7 Requirements for volumes (scalability)
The system must support access to data for 10 years.
The estimated increase in database volume per day of operation is 20 MB.
4.8 Requirements for the number, functions and qualifications of IS personnel and their mode of operation
Work with the IS will be carried out by the following Customer personnel:
Administrator:
Quantity: 1;
Qualification: network administrator, database administrator;
Functions: system security management, backup data at the beginning of each working day, data archiving once a year;
Working hours: 1 hour a day, 5 days a week
The operator (user) who records the fact of a trading operation and analyzes the results of trading activities:
Quantity: 2;
Qualification: accountant, PC user;
Functions: input primary documents, maintaining the current state of information about the warehouse, generating accounting entries, analyzing the results of trading activities, backing up data at the beginning of the working day that falls on Saturday and Sunday.
Working hours: in shifts to ensure system operation 11 hours a day, 7 days a week;
Access to work: 8-hour training course;
Before putting the IS into operation, in order to obtain permission to work, personnel must complete an 8-hour training course. After completing the course, testing is carried out, during which the correctness and speed of solving practical problems, as well as knowledge of job and technical instructions are assessed.
The system should provide access to its functions only to registered IS users by specifying a password.
4.10 Requirements for software and composition, structure and methods of organizing the IS database
Data in the System must be stored in relational DBMS MS SQL Server 2000.
- T-SQL (SQL language dialect);
WITH # .
The software consists of general system software purchased at the expense of the Customer (purchased software), and special software developed as part of the work on creating IP.
The following software should be used as system-wide software:
Operating system;
Database management system MS SQL Server 2000;
Backup software;
4.11 Hardware requirements
Database server, 2 workstations.
Network throughput is 100 Mbit per second.
4.12 Requirements for development prospects and IS modernization
It must be possible to modernize and develop the IS without involving the Developer by the IS administrator at the level of:
- adding, changing, deleting IS reference information;
- connecting/removing new IS users;
- password changes;
- import/export data from/to external sources data.
It should be possible to modernize and develop the IS with limited participation of the Developer (telephone consultations) at the level of modernizing old reports and creating new reports. The possibility and conditions of telephone consultation by the Developer on IS modernization are negotiated separately by signing a new agreement.
5. Composition and content of work to create the system
Work on the design of the IS “Accounting for Trade Operations” is carried out in three stages.
The first stage includes:
Checking the possibility of obtaining all the information requested by the Customer based on the initial data;
IS database design;
Filling the developed database test set data;
Development of user interface design;
Development of a low-level technical specification for the development of the IS “Accounting for Trade Operations”
The end of the first stage is confirmed by the signing of the internal Certificate of Work Completed and the approval of the low-level technical specification for the development of the IP.
The second stage is the development of a test version of the IS “Accounting for Trade Operations”. Ending this stage is to put the test version into trial operation.
The third stage is the trial operation of the IS “Accounting for Trade Operations”, which includes the elimination of identified errors, shortcomings and inconsistencies with this Technical Specification. The end of the second stage is the introduction of the IS into commercial operation.
The completion of each second and third stage is confirmed by the Parties to the agreement by signing the Transfer and Acceptance Certificate.
The duration of the first stage is 10 days. The beginning of the first stage is considered to be the day following the day the Customer and the DB Developer signed this Technical Specification.
The duration of the second stage is 20 days. The beginning of the second stage is considered to be the day following the day of approval of the low-level technical specification for the development of IP.
The duration of the third stage is 20 days. The beginning of the third stage is considered to be the day following the day the Customer and the DB Developer signed the Acceptance Certificate of the test version of the IS for trial operation.
The data set for testing the IS is provided by the Customer.
Upon completion of the second stage of work, the DB Developer installs a test IS on the Customer’s test server and provides the Customer with preliminary guidance user, containing a description of the procedures necessary to work with the IS “Accounting for Trade Operations”. Descriptions are provided electronically.
At the end of the third stage of work, the DB Developer provides the Customer with a program for installing the database on the server, as well as user and programmer instructions and instructions for installing the IS with descriptions of the procedures necessary to work with the IS “Accounting for Trade Operations”.
6. Procedure for control and acceptance of the system
At the end of the first stage, an internal Certificate of Work Completed is signed and the low-level work is approved data sheet for IP development.
At the end of the second and third stages of design, the Developer installs the IS at the Customer, demonstrates the operation of the IS in accordance with the requirements set out in this Technical Specification, and signs the Transfer and Acceptance Certificate.
7. Requirements for the composition and content of work to prepare the automation object for commissioning of the system
On the day of the start of trial operation, the Customer is obliged to provide the Developer with the necessary access to the server on which the test version of the “Trade Operations Accounting” IS will be deployed.
The lack of a server for installing the IS “Accounting for Trade Operations” database cannot be a basis for refusal to sign the Acceptance Certificate for the IS “Accounting for Trade Operations” for trial or commercial operation.
At the end of the second stage of developing the IS “Accounting for Trade Operations,” the Developer conducts an 8-hour training course with the Customer’s personnel on IS maintenance. Upon completion this course The Customer's personnel are tested.
8. Documentation requirements
At the end of the third stage, the Developer of the IS “Accounting for Trade Operations” transfers the following documentation to the Customer:
1. Programmer's instructions.
The Programmer's Instructions describe the procedures necessary to work with the “Trade Operations Accounting” IS. Description of procedures includes:
Name of the procedure;
Description of the actions performed by the procedure;
Description of the input parameters, indicating the parameter type, its recording format and the default value, if one is defined for the parameter;
Description of output parameters and (or) return sets of records, indicating their types and formats
An example of a procedure call and the values it returns. If a procedure can have several calling options, then examples for each option.
2. Instructions for installing the IS “Accounting for Trade Operations”.
3. Instructions for the user of the IS “Accounting for trade operations”.
No other documentation is provided to the Customer. Instructions are provided in both printed and electronic formats. Instructions in printed form provided in one copy.
The uniqueness of IP as a product for industrial and technical purposes, expressed in its complexity, in the absence of standards for most types of procedures and work, makes the process of their planning and design very complex and difficult. When an enterprise interacts with an IS developer for any purpose, two main documents are required to begin work: an agreement and a technical specification (TOR). Drawing up technical specifications is a separate task. The technical specification itself, in fact, is a document that reflects all the wishes of the customer; it should be drawn up in as much detail as possible, and indicate all the details and vision of the result. Only on its basis will it be determined what the developers are required to do, so the terms of reference should be drawn up in as much detail as possible.
When designing any information systems, they are required detailed description. For these purposes you can use various ways and methods, but the most effective solution is to develop technical specifications (TOR), which describe the goals, objectives, interface and other requirements for the object being developed.
A technical specification is a document that defines the goals, requirements and basic input data necessary for the development of an IS. The technical specification for an IP is the main document that defines the requirements and procedure for the creation, development or modernization of an IP, in accordance with which its development, commissioning and acceptance are carried out.
Success in implementing IP lies in the correctness of the task set by the customer. If all the necessary conditions to write a good technical specification are completed, then the result will turn from expected into feasible.
by the customer himself;
by the contractor, but in this case, his responsibilities will include design and testing;
competitive performers, whose duties include only writing technical specifications;
by third party contractors.
For those technical specifications that are written by the contractor, there are a number of regulatory documentation:
GOST 21.408-93 “Rules for the implementation of working documentation for automation of technological processes”;
GOST 34.201-89 “Types, completeness and designation of documents when creating automated systems”;
GOST 24.703-85 “Standard design solutions in automated control systems. Basic provisions";
GOST 34.003-90 “Automated systems. Terms and Definitions";
GOST 34.601-90 “Automated systems. Stages of creation";
GOST 34.602-90 “Technical specifications for the creation of an automated system”;
GOST 19.201-78 Unified system of program documentation;
GOST 2.114-95 Unified system of design documentation.
Technical specification for an IS is a list of basic operational, technological, technical, organizational, software, information-logical and linguistic, economic and other requirements that the IS must satisfy at all stages of its existence.
TK is text document, compiled in any form. It is recommended to submit the necessary drawings, diagrams and large tables in the form of attachments. Depending on the type, purpose and specific features automation object and the operating conditions of the system, it is allowed to draw up sections of the technical specifications in the form of applications, introduce additional ones, exclude or combine its subsections.
There are no specific recommendations on what the technical specification should contain, which means sections and subsections must be developed and placed in the order established by the contractor. There are only General characteristics sections and subsections. The developer can independently change, add and edit their name and quantity.
Sheet (page) numbers are placed, starting from the first sheet following the title page, at the top of the sheet (above the text, in the middle) after indicating the TK code on the IS.
The signatures of the customer, developer and approving companies are placed on the title page and sealed. If necessary, the title page is drawn up on several pages. The signatures of the developers of the technical specifications and officials involved in the approval and consideration of the draft technical specifications for the IP are placed on the last sheet.
The title page of the addition to the technical specifications is designed in the same way title page technical specifications. Instead of the name “Technical specifications” they write “Addition No.... to the technical specifications for AC...”
On subsequent sheets of the addition to the technical specifications, the basis for the change, the content of the change and links to the documents in accordance with which these changes are made are placed.
When presenting the text of an addition to the technical specifications, you should indicate the numbers of the corresponding paragraphs, subparagraphs, tables of the main technical specifications, etc. and use the words: “replace”, “supplement”, “exclude”, “state in a new edition”.
At the initial stage of development of technical specifications, the contractor creates a rough content plan.
General information;
Purpose and goals of creating the system;
Characteristics of the automation object;
System requirements;
Terms of Use;
Requirements for program documentation;
Technical and economic indicators;
Stages and stages of development;
Control and acceptance procedure.
These sections can be divided into subsections. The technical specifications may also include applications that are described according to established standards. The contractor can add or delete necessary sections as necessary; all these factors must be agreed upon with the customer. By adhering to the established plan, the contractor can develop technical specifications efficiently and in a short time.
If necessary, the performer creates a list of accepted abbreviations and a glossary.
Terms of reference for IP development medical institution posted in Appendix B.
Development of an information system for recording the work of a construction enterprise
2. Terms of reference for the creation of an information system
2.1 General information
Automated information system "Construction enterprise"
2.2 Goals of creating an information system
To solve the problems of control and accounting of design, manufacturing, and sales, an automated information system is being created in this enterprise, which is designed in the ACCESS DBMS environment.
Information in the form distributed base data is stored partly on the file server and partly on workstations that are part of the local computer network sales department. A type of automated activity is accounting.
The main means of operation of this company are the buildings of the enterprise ZAO UniStroy - NN, which houses control automation equipment (computers - workstations, servers, as well as other technical devices).
The main functions that the IS solves:
· Monitoring the operation of the enterprise;
· Accounting for company sales;
· Accounting for results (income and expenses of the enterprise).
Systematization and automatic control over the work of the enterprise, sales, orders.
2.3 Characteristics of automation objects
Main activity of this enterprise is the organization of the design and sale of goods, which means that the accounting activities of the economic department will be the main object of automation.
2.4 System requirements
2.4.1 Requirements for input, reference and output information
The input information of the design, manufacturing, and sales department includes the data necessary to solve all the problems solved in this department. In the primary form, this data comes in the form of paper documents. The main input information includes the following data:
· Documents received from the economic planning department once a month, which contain planned tasks for design and sales;
· Data coming from the marketing department, which contains requests for the supply of goods and other work, information about established prices;
The output information can be presented in the form of a paper document, in the form of an information message, or in the form of a file (electronic document) on magnetic media.
This data is presented in the form of a database table, in the form of a query, and also in the form of a report on the screen and on paper.
The output results of solving the problem of accounting for the results of an enterprise's activities are displayed:
· To the printer and to HDD in the design and manufacturing department, and the sales department;
· Transmitted via communication channel to the accounting department and the economic planning department.
Output data is issued every quarter.
2.4.2 Proposals for coding and classification of information
Encoding of input information must be carried out taking into account the following requirements:
· Reducing time and other costs for solving problems in the control system;
· Ensuring high quality information.
The information system uses an ordinal method of encoding input information (Table: Design and manufacturing accounting, field - record number, Sales accounting - record number).
This data is encoded using the ordinal method. Its advantage is ease of use, the disadvantage is code overflow.
Classification of information.
There are 2 classification methods:
· Hierarchical - this classification method is understood as a method in which a given set is sequentially divided into subordinate subsets, gradually specifying the object of classification. In this case, the basis of division is some selected characteristic. The totality of the resulting groupings forms a hierarchical tree structure in the form of a branching graph, the nodes of which are the groupings.
· Facet - this method of classification involves the parallel division of many objects into independent classification groups. In this case, a rigid classification structure and pre-constructed final groupings are not assumed. Classification groupings are formed by combining values taken from the corresponding facets.
The quality of information in management systems is a set of properties that determine the suitability of data to meet the needs of the management system. The most important properties information used in control systems are:
Ш Cumulativeness - completeness of information;
Ш Reliability - absence of hidden errors;
Ш Security - impossibility of unauthorized access;
Ш Efficiency - timeliness;
Ш Homomorphy - data must be presented in one form;
Ш Identity - the correspondence of objects at the moment;
Ш Confidentiality - secrecy.
The main software method for monitoring the quality of information used in the management system is:
· Logical - semantic check, i.e. control by deviations, according to a given sequence of records
· Software.
In this work, information quality control is carried out using the “Reliability Control” button. The tables are checked: products, projects and sales accounting. If the table contains negative values for production cost, sales price, design cost and quantity, then an error is detected when the button is pressed. Otherwise, it is reported that there are no errors.
2.4.4 Proposed measures to protect information from unauthorized access
Unauthorized access - obtaining information without the permission of its owner.
Its types:
1. Indirect - listening devices, remote photographs, radio interception, etc.
2. Direct - direct theft of storage media, reading data from the disk, logging into the system using someone else's password, masking requests under system requests, infection with software viruses, etc.
The most vulnerable part of information is protected using the following methods:
· Procedural - organizational - technical measures - identification of all computers and users, establishment of work regulations, specific databases and programs.
· Software - database protection and application programs from copying, antivirus programs, encryption, information backup
The information system uses software method protection (virus scanning).
The database was created in the ACCESS DBMS system because it is more focused on regular user, in comparison, for example, with the FOXPRO DBMS, which is aimed at the application programmer. The choice of DBMS is determined by the level of complexity of the management tasks solved as part of the AIS. Therefore for this course work ACCESS DBMS is optimal.
2.4.5 Requirements for the database (DB) and DB management system
The database management system that will be used in the automated system is the ACCES DBMS, since it is more focused on the average user, and the FOXPRO DBMS is more focused on the application programmer.
2.4.6 Requirements for technical means
It is recommended to use a PC with a Pentium-IV processor, with RAM volume of at least 256 MBt, with disk memory with a capacity of at least 200 Gb. This will ensure high-performance LAN operation when using any topology and operating system.
Requirements for auxiliary devices. To work on the network, 32-bit are installed network adapters EtherNet with ISA protocol or TokenRing adapters with MicroChannel protocol, or ArcNet network adapters with ISA protocol.
The network printer must meet the following requirements:
· Have high performance;
· Have sufficient buffer memory;
· Have high reliability work;
· Provide high quality printing;
· It is advisable to be able to copy documents.
Based on this, it applies laser printer- HP LaserJet 1100.
To increase the reliability of the network, it is necessary to install devices uninterruptible power supply UPS, especially for file servers.
3. Technical working draft (Design solution)
Automation of the plagiarism search process
Automation of technical support for users
In accordance with GOST 34.601-90, this standard applies to automated systems(AS) used in various types of activities (research, design, management, etc.), including their combinations created in organizations...
Automation of calculations for wages using the example of Nechkinskoye OJSC, Sarapul district of the Udmurt Republic using the 1C:Enterprise 8.0 program
Automated information system for water consumption metering
General information Full name of the system and its symbol Information system for recording water consumption using the example of the limited liability company "Vodosnabzhenie" (AIS URV "Vodosnabzhenie")...
Automated information system for recording the storage and maintenance of control and measuring instruments
The technical specifications were developed in accordance with GOST 34.602-89 " Information technology. Set of standards for automated systems. Terms of reference for the creation of an automated system "...
Virtual dean's office
To update the site from the Branch is provided new information, photos and media files that need to be replaced on any of the pages. Replacement is carried out using the instructions in step 2...
Information system "Klinnik"
1. Determining the purpose of the developed IS: Improve the quality of customer service for the organization, speed up the documentation process. 2...
Information support for ATP
We select technical support taking into account the organizational structure of the service station...
Information network design
The purpose of the coursework will be to develop information network in municipal educational institution gymnasium No. 7, physically located in a one-story building...
Development of an organization’s website (based on materials from Avtomir LLC, Gomel)
Let's consider the level of technical support at Avtomir LLC. All jobs in the organization are automated. Personal computers are installed at workplaces...
Development and design of an information system for a salon mobile communications with help Microsoft Access in the language Visual programming Basic
One of the stages of designing an automated information system is the development and approval of technical specifications for the creation of the system. The technical specification is the main document...
Development of an information system for the network administrator of the organization LLC "WestCall"
Development of an accounting system for computer and office equipment and Supplies
1 General information. 1.1 Full name of the system and its symbol "Bentec IT & Soft invent" 2. Purpose and goals of creating the system. 2.1 Purpose of the system...
Development of technical specifications for the automation of the Bukva store
General information Name of the system: automated system for recording the activities of the store "Bukva-Serov". The customer company is Etalon LLC...
Creating a group site
1) Product type: Dynamic group website; 2) Goal: Creation of a group website for the convenience of informing group students during non-school and academic hours; 3) Target audience: Group students and university teachers; 4) Requirements for the site: 1) Convenient...
GOST 34.602-89 Information technology. A set of standards for automated systems. Technical specifications for the creation of an automated system (Instead of GOST 24.201-85)
Date of introduction from 01/01/1990
This standard applies to automated systems (AS) for automating various types of activities (management, design, research, etc.), including their combinations, and establishes the composition, content, rules for drawing up the document “Technical specifications for the creation (development or modernization) systems" (hereinafter referred to as TK for the AS).
1. GENERAL PROVISIONS
1.1. The technical specification for a nuclear power plant is the main document that defines the requirements and procedure for creating (development or modernization - then creation) of an automated system, in accordance with which the development of the nuclear power plant is carried out and its acceptance upon commissioning.
1.2. Specifications for the NPP are developed for the system as a whole, intended to operate independently or as part of another system.
Additionally, technical specifications for parts of the NPP can be developed:
- for AS subsystems, AS task complexes, etc. in accordance with the requirements of this standard;
- for hardware components and software and hardware systems in accordance with ESKD and SRPP standards;
- for software in accordance with ESPD standards;
- for information products in accordance with GOST 19.201 and NTD valid in the department of the customer of the AS.
Note. The technical specifications for an automated control system for a group of interconnected objects should include only requirements common to the group of objects. Specific Requirements separate object management should be reflected in the technical specifications for the automated control system of this facility.
1.3. Requirements for AS in the scope established by this standard can be included in the design assignment for a newly created automation facility. In this case, technical specifications for the nuclear power plant are not developed.
1.4. The requirements included in the technical specifications for nuclear power plants must correspond to the current level of development of science and technology and not be inferior to similar requirements imposed on the best modern domestic and foreign analogues. The requirements specified in the technical specifications for the NPP should not limit the system developer in the search and implementation of the most effective technical, technical, economic and other solutions.
1.5. Technical specifications for nuclear power plants are developed on the basis of initial data, including those contained in the final documentation of the stage “Research and justification for the creation of nuclear power plants”, established by GOST 24.601.
1.6. The technical specifications for the AS include only those requirements that complement the requirements for systems of this type (ACS, CAD, ASNI, etc.) contained in the current normative and technical documentation, and are determined by the specifics of the specific object for which the system is being created.
1.7. Changes to the technical specifications for the NPP are formalized by an addition or a protocol signed by the customer and developer. The addition or the specified protocol is an integral part of the technical specifications for the NPP. On the title page of the technical specification for the speaker there should be the entry “Valid from...”.
2. COMPOSITION AND CONTENTS
2.1. The technical specification for the NPP contains the following sections, which can be divided into subsections:
- 1) general information;
- 2) the purpose and goals of the creation (development) of the system;
- 3) characteristics of automation objects;
- 4) system requirements;
- 5) composition and content of work to create the system;
- 6) procedure for control and acceptance of the system;
- 7) requirements for the composition and content of work to prepare the automation object for putting the system into operation;
- 8) documentation requirements;
- 9) sources of development.
Applications may be included in the technical specifications for the speakers.
2.2. Depending on the type, purpose, specific features of the automation object and the operating conditions of the system, it is possible to draw up sections of the technical specifications in the form of applications, introduce additional ones, exclude or combine subsections of the technical specifications.
The technical specifications for parts of the system do not include sections that duplicate the contents of the technical specifications sections for the system as a whole.
2.3. In the “General Information” section indicate:
- 1) full name of the system and its symbol;
- 2) subject code or code (number) of the contract;
- 3) the name of the enterprises (associations) of the developer and customer (user) of the system and their details;
- 4) a list of documents on the basis of which the system is created, by whom and when these documents were approved;
- 5) planned dates for the start and end of work on creating the system;
- 6) information about the sources and procedure for financing the work;
- 7) the procedure for registration and presentation to the customer of the results of work on creating the system (its parts), on the production and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.
2.4. Section “Purpose and goals of creation (development) of the system” consists of subsections:
- 1) purpose of the system;
- 2) the goals of creating the system.
2.4.1. In the subsection “Purpose of the system” they indicate the type of activity being automated (management, design, etc.) and the list of automation objects (facilities) on which it is supposed to be used.
For automated control systems, a list of automated control bodies (points) and controlled objects is additionally indicated.
2.4.2. In the subsection “Goals for creating a system”, the names and required values of technical, technological, production, economic or other indicators of the automation object that must be achieved as a result of creating an automated system are given, and indicate the criteria for assessing the achievement of the goals for creating the system.
2.5. In the section “Characteristics of the automation object” the following is given:
- 1) brief information about the automation object or links to documents containing such information;
- 2) information about the operating conditions of the automation object and the characteristics of the environment.
Note: For CAD, the section additionally provides the main parameters and characteristics of design objects.
2.6. The “System Requirements” section consists of the following subsections:
- 1) requirements for the system as a whole;
- 2) requirements for functions (tasks) performed by the system;
- 3) requirements for types of security.
The composition of the requirements for the system included in this section of the technical specifications for the NPP is established depending on the type, purpose, specific features and operating conditions of a particular system. Each subsection provides links to the current normative and technical documentation that defines the requirements for systems of the corresponding type.
2.6.1. In the subsection “Requirements for the system as a whole” indicate:
- requirements for the structure and functioning of the system;
- requirements for the number and qualifications of system personnel and their mode of operation;
- destination indicators;
- reliability requirements;
- safety requirements;
- requirements for ergonomics and technical aesthetics;
- transportability requirements for mobile speakers;
- operating requirements, maintenance, repair and storage of system components;
- requirements for protecting information from unauthorized access;
- requirements for the safety of information in case of accidents;
- requirements for protection from external influences;
- requirements for patent purity;
- requirements for standardization and unification;
- Additional requirements.
2.6.1.1. The requirements for the structure and operation of the system include:
- 1) a list of subsystems, their purpose and main characteristics, requirements for the number of hierarchy levels and the degree of centralization of the system;
- 2) requirements for methods and means of communication for information exchange between system components;
- 3) requirements for the characteristics of relationships created system with related systems, requirements for its compatibility, including instructions on methods of information exchange (automatically, by sending documents, by telephone, etc.);
- 4) requirements for system operating modes;
- 5) requirements for diagnosing the system;
- 6) prospects for development and modernization of the system.
2.6.1.2. The requirements for the number and qualifications of personnel at nuclear power plants include:
- requirements for the number of personnel (users) of the plant;
- requirements for personnel qualifications, the procedure for their training and control of knowledge and skills;
- required operating mode for plant personnel.
2.6.1.3. In the requirements for indicators of the purpose of the AS, the values of parameters characterizing the degree of compliance of the system with its purpose are given.
For ACS indicate:
- the degree of adaptability of the system to changes in processes and control methods, to deviations in the parameters of the control object;
- acceptable limits of modernization and development of the system;
- probabilistic-time characteristics under which the intended purpose of the system is preserved.
2.6.1.4. Reliability requirements include:
- 1) composition and quantitative values of reliability indicators for the system as a whole or its subsystems;
- 2) list emergency situations, according to which reliability requirements and the values of the corresponding indicators should be regulated;
- 3) reliability requirements technical means and software;
- 4) requirements for methods for assessing and monitoring reliability indicators at different stages of system creation in accordance with current regulatory and technical documents.
2.6.1.5. The safety requirements include requirements for ensuring safety during installation, commissioning, operation, maintenance and repair of technical equipment of the system (protection from the effects electric current, electromagnetic fields, acoustic noise, etc.), according to permissible levels of illumination, vibration and noise loads.
2.6.1.6. The requirements for ergonomics and technical aesthetics include speaker indicators that specify required quality human-machine interaction and comfortable working conditions for personnel.
2.6.1.7. For mobile speakers, the requirements for transportability include design requirements that ensure the transportability of the technical means of the system, as well as requirements for vehicles.
2.6.1.8. Requirements for operation, maintenance, repair and storage include:
- 1) conditions and regulations (mode) of operation, which must ensure the use of technical means (TS) of the system with specified technical indicators, including the types and frequency of maintenance of the TS of the system or the admissibility of operation without maintenance;
- 2) preliminary requirements for the permissible areas for accommodating personnel and vehicle systems, for the parameters of power supply networks, etc.;
- 3) requirements for the number, qualifications of service personnel and their operating modes;
- 4) requirements for the composition, placement and storage conditions of a set of spare products and devices;
- 5) requirements for maintenance regulations.
2.6.1.9. The requirements for protecting information from unauthorized access include the requirements established in the scientific and technical documentation applicable in the customer’s industry (department).
2.6.1.10. The requirements for the safety of information provide a list of events: accidents, failures of technical equipment (including loss of power), etc., in which the safety of information in the system must be ensured.
2.6.1.11. The requirements for means of protection against external influences include:
- 1) requirements for radioelectronic protection of nuclear power plants;
- 2) requirements for durability, stability and strength to external influences (environment of use).
2.6.1.12. The requirements for patent purity indicate a list of countries in respect of which the patent purity of the system and its parts must be ensured.
2.6.1.13. The requirements for standardization and unification include: indicators establishing the required degree of use of standard, unified methods for implementing functions (tasks) of the system, supplied software, standard mathematical methods and models, standard design solutions, unified forms of management documents established by GOST 6.10.1, All-Union classifiers of technical and economic information and classifiers of other categories in accordance with their scope of application, requirements for the use of standard automated workstations, components and complexes.
2.6.1.14. Additional requirements include:
- 1) requirements for equipping the system with devices for personnel training (simulators, other devices for similar purposes) and documentation for them;
- 2) requirements for service equipment, stands for testing system elements;
- 3) system requirements associated with special conditions operation;
- 4) special requirements at the discretion of the system developer or customer.
2.6.2. In the subsection “Requirements for functions (tasks)” performed by the system, the following is given:
when creating a system in two or more stages - a list of functional subsystems, individual functions or tasks put into effect in the 1st and subsequent stages;
2.6.3. In the subsection “Requirements for types of support,” depending on the type of system, requirements for mathematical, information, linguistic, software, technical, metrological, organizational, methodological and other types of support for the system are given.
2.6.3.1. For the mathematical support of the system, requirements are given for the composition, scope of application (limitations) and methods of using mathematical methods and models in the system, standard algorithms and algorithms to be developed.
2.6.3.2. The requirements for information support of the system are:
- 1) to the composition, structure and methods of organizing data in the system;
- 2) to information exchange between system components;
- 3) to information compatibility with related systems;
- 4) on the use of all-Union and registered republican, industry classifiers, unified documents and classifiers operating at a given enterprise;
- 5) on the use of database management systems;
- 6) to the structure of the process of collecting, processing, transmitting data in the system and presenting data;
- 7) to protect data from destruction during accidents and system power failures;
- 8) to control, store, update and restore data;
- 9) to the procedure of giving legal force documents produced by technical means of the NPP (in accordance with GOST 6.10.4).
2.6.3.3. For linguistic support of the system, requirements for the use of programming languages in the system are given. high level, user interaction languages and system hardware, as well as requirements for data encoding and decoding, data input/output languages, data manipulation languages, description tools subject area(automation object), to ways of organizing dialogue.
2.6.3.4. For system software, a list of purchased software is provided, as well as requirements:
- 1) to the independence of software from the used SVT and operating environment;
- 2) to the quality of software, as well as to the methods of its provision and control;
- 3) if necessary, coordinate newly developed software with the fund of algorithms and programs.
2.6.3.5. For technical support of the system the following requirements are given:
- 1) to the types of technical means, including the types of complexes of technical means, software and hardware complexes and other components allowed for use in the system;
- 2) to the functional, design and operational characteristics of the system’s technical support means.
2.6.3.6. The requirements for metrological support include:
- 1) preliminary list measuring channels;
- 2) requirements for the accuracy of measurements of parameters and (or) for the metrological characteristics of measuring channels;
- 3) requirements for metrological compatibility of technical means of the system;
- 4) list of managers and computing channels systems for which it is necessary to evaluate the accuracy characteristics;
- 5) requirements for metrological support of hardware and software included in the system’s measuring channels, built-in control tools, metrological suitability of measuring channels and measuring instruments used during commissioning and testing of the system;
- 6) type of metrological certification (state or departmental) indicating the procedure for its implementation and the organizations conducting certification.
2.6.3.7. For organizational support the following requirements are given:
2.6.3.8. For methodological support, CAD provides requirements for the composition of the regulatory and technical documentation of the system (a list of standards, regulations, methods, etc. used in its operation).
2.7. The section “Composition and content of work on the creation (development) of the system” should contain a list of stages and phases of work on the creation of the system in accordance with GOST 24.601, the timing of their implementation, a list of organizations performing the work, links to documents confirming the consent of these organizations to participate in creation of a system, or a record identifying the person responsible (customer or developer) for carrying out this work.
This section also provides:
- 1) a list of documents, in accordance with GOST 34.201-89, presented at the end of the relevant stages and phases of work;
- 2) type and procedure for conducting the examination of technical documentation (stage, stage, volume of documentation being checked, expert organization);
- 3) a program of work aimed at ensuring the required level of reliability of the system being developed (if necessary);
- 4) a list of works on metrological support at all stages of creating the system, indicating their deadlines and executing organizations (if necessary).
2.8. In the section “Procedure for control and acceptance of the system” indicate:
- 1) types, composition, scope and testing methods of the system and its components(types of tests in accordance with current standards applicable to the system being developed);
- 2) general requirements for the acceptance of work by stages (list of participating enterprises and organizations, place and timing), the procedure for coordination and approval of acceptance documentation;
- H) status of the acceptance committee (state, interdepartmental, departmental).
2.9. In the section “Requirements for the composition and content of work to prepare the automation object for commissioning of the system,” it is necessary to provide a list of the main activities and their performers that should be performed when preparing the automation object for putting the plant into operation.
The list of main activities includes:
- 1) bringing the information entering the system (in accordance with the requirements for information and linguistic support) to a form suitable for processing using a computer;
- 2) changes that need to be made in the automation object;
- 3) creation of conditions for the functioning of the automation object, under which the compliance of the created system with the requirements contained in the technical specifications is guaranteed;
- 4) creation of units and services necessary for the functioning of the system;
- 5) timing and procedure for staffing and training.
For example, for automated control systems they give:
- changes in applied management methods;
- creating conditions for the operation of automated control system components, under which the system’s compliance with the requirements contained in the technical specifications is guaranteed.
2.10. In the “Documentation Requirements” section the following is given:
- 1) a list of sets and types of documents to be developed, agreed upon by the developer and the Customer of the system, that meet the requirements of GOST 34.201-89 and NTD of the customer’s industry;
list of documents issued on computer media;
requirements for microfilming documentation; - 2) requirements for documenting component elements for cross-industry use in accordance with the requirements of the ESKD and ESPD;
- 3) in the absence of state standards defining the requirements for documenting system elements, additionally include requirements for the composition and content of such documents.
2.11. The “Sources of Development” section should list documents and information materials(feasibility study, reports on completed research work, information materials on domestic and foreign analogue systems, etc.), on the basis of which the technical specifications were developed and which should be used when creating the system.
2.12. In the presence of approved methods, the technical specifications for nuclear power plants include annexes containing:
- 1) calculation of the expected efficiency of the system;
- 2) assessment of the scientific and technical level of the system.
Applications are included in the technical specifications for the NPP as agreed between the developer and the customer of the system.
3. REGISTRATION RULES
3.1. Sections and subsections of the technical specifications for the NPP must be placed in the order established in section. 2 of this standard.
3.2. Technical specifications for the AS are drawn up in accordance with the requirements of GOST 2.105.95 on A4 sheets in accordance with GOST 2.301 without a frame, main inscription and additional columns to it.
Sheet (page) numbers are placed, starting from the first sheet following the title page, at the top of the sheet (above the text, in the middle) after indicating the TK code on the AC.
3.3. The values of indicators, norms and requirements are indicated, as a rule, with maximum deviations or maximum and minimum values. If these indicators, norms, and requirements are clearly regulated by the scientific and technical documentation, the technical specifications for the plant should contain a link to these documents or their sections, as well as additional requirements that take into account the features of the system being created. If specific values of indicators, norms and requirements cannot be established during the development of technical specifications for the NPP, it should make a record of the procedure for establishing and agreeing on these indicators, norms and requirements:
“The final requirement (value) is clarified in the process... and agreed upon by the protocol with... at the stage...”
At the same time, no changes are made to the text of the technical specifications for the NPP.
3.4. The title page contains the signatures of the customer, developer and approving organizations, which are sealed with an official seal. If necessary, the title page is drawn up on several pages. The signatures of the developers of the technical specifications for the nuclear power plant and the officials involved in the approval and consideration of the draft technical specifications for the nuclear power plant are placed on the last sheet.
The form of the title page of the terms of reference for the AS is given in Appendix 2. Form last sheet The terms of reference for the NPP are given in Appendix 3.
3.5. If necessary, it is allowed to place codes established in the industry on the title page of the technical specifications for the speakers, for example: security classification, work code, registration number TK, etc.
3.6. The title page of the addition to the technical specifications for the NPP is designed in the same way as the title page of the technical specifications. Instead of the name “Technical specifications” they write “Addition No. ... to the technical specifications for AC...”.
3.7. On subsequent sheets of the addendum to the technical specifications for the AS, the basis for the change, the content of the change and links to the documents in accordance with which these changes are made are placed.
3.8. When presenting the text of an addition to the technical specifications, you should indicate the numbers of the corresponding paragraphs, subparagraphs, tables of the main technical specifications on the AS, etc. and use the words: “replace”, “supplement”, “exclude”, “state in a new edition”.
PROCEDURE FOR DEVELOPMENT, APPROVAL AND APPROVAL OF TOR FOR NPP
1. The draft technical specifications for the NPP are developed by the system developer organization with the participation of the customer on the basis technical requirements(applications, tactical and technical specifications, etc.).
During the competitive organization of work, options for the design specifications for the NPP are considered by the customer, who either selects the preferred option, or, based on a comparative analysis, prepares the final version of the technical specifications for the AC with the participation of the future NPP developer.
2. The need for coordination of the draft technical specifications for the NPP with state supervisory authorities and other interested organizations is determined jointly by the customer of the system and the developer of the project technical specifications for the nuclear power plant,
The work on coordinating the draft technical specifications for the AC is carried out jointly by the developer of the technical specifications for the AC and the customer of the system, each in the organizations of his ministry (department).
3. The period for approval of the draft technical specifications for the NPP in each organization should not exceed 15 days from the date of its receipt. It is recommended to send copies of the draft technical specifications for the AS (copies) simultaneously to all organizations (divisions) for approval.
4. Comments on the draft technical specifications for the NPP must be submitted with a technical justification. Decisions on comments must be made by the developer of the draft technical specifications for the nuclear power plant and the customer of the system before approval of the technical specifications for the nuclear power plant.
5. If, when agreeing on a draft technical specification for a nuclear power plant, disagreements arise between the developer and the customer (or other interested organizations), then a protocol of disagreements is drawn up (the form is arbitrary) and a specific decision is made in the prescribed manner.
6. Approval of the draft technical specifications for the NPP may be formalized in a separate document (letter). In this case, under the heading “Agreed” a link is made to this document.
7. The approval of technical specifications for the NPP is carried out by the heads of enterprises (organizations) of the developer and customer of the system.
8. Before submitting it for approval, the technical specification for the NPP (addition to the technical specification) must be checked by the regulatory control service of the organization that developed the technical specification and, if necessary, subjected to metrological examination.
9. Copies of the approved technical specifications for the plant are sent by the developer of the technical specifications for the plant to the participants in the creation of the system within 10 days after approval.
10. Coordination and approval of additions to the technical specifications for the nuclear power plant are carried out in the manner established for the technical specifications for the nuclear power plant.
11. Changes to the technical specifications for the NPP are not allowed to be approved after the system or its turn is submitted for acceptance testing.
12. Registration, accounting and storage of technical specifications on the NPP and additions to it are carried out in accordance with the requirements of GOST 2.501.
FORM OF THE TITLE PAGE OF THE TOR ON THE AC
________________________________________________________
|
Name I APPROVED Supervisor Personal signature Seal date I APPROVED Supervisor Personal signature Seal date
name of the type of speaker
Object name
abbreviated TECHNICAL TASK On ____ sheets Valid AGREED Supervisor Personal signature Seal date |
FORM OF THE LAST SHEET OF THE TOR ON THE AC
(code TK)MADE AGREED
APPENDIX 4
Information
PROVISIONS FOR THE CREATION OF A UNIFIED SET OF AUTOMATED SYSTEMS STANDARDS
1. Initial prerequisites for creating the complex
1.1. Creation and implementation of automated systems various classes and appointments are carried out in many industries according to regulatory and technical documentation that establishes a variety of organizational, methodological and technical standards, rules and regulations that complicate the integration of systems and their effective joint functioning.
1.2. During the period when the USSR State Standard made a decision on improving inter-industry complexes of standards, the following complexes and systems of standards were in force, establishing requirements for various types AC:
- 1) one system standards for automated control systems (24th system), covering automated control systems, automated control systems, process control systems and other organizational and economic systems;
- 2) a set of standards (system 23501); extending to computer-aided design systems;
- 3) the fourth group of the 14th system of standards, which applies to automated systems for technological preparation of production.
1.3. The practice of applying standards for automated control systems, CAD, automated process control systems, automated process control systems has shown that they use the same conceptual apparatus, there are many common facilities standardization, however, the requirements of the standards are not consistent with each other, there are differences in the composition and content of the work, differences in the designation, composition, content and execution of documents, etc.
1.4. Against the backdrop of the absence of a unified technical policy in the field of creating AS, the variety of standards did not ensure broad compatibility of AS during their interaction, did not allow systems to be replicated, and hampered the development of promising areas for the use of computer technology.
1.5. Currently, a transition is being made to the creation of complex automated systems (abroad, CAD - CAM systems), which include automated control systems technological processes and production, CAD - designer, CAD - technologist, ASNI and other systems. The use of conflicting rules when creating such systems leads to a decrease in quality, an increase in the cost of work, and a delay in the commissioning of nuclear power plants.
1.6. A unified set of standards and guidance documents should apply to automated systems for various purposes: ASNI, CAD, OASU, ASUP, ASUTP, ASUGPS, ASK, ASPP, including their integration.
1.7. When developing cross-industry documents, one should take into account following features AS as objects of standardization:
- 1) the technical specification is the main document in accordance with which the creation of the AS is carried out and its acceptance by the customer;
- 2) NPPs, as a rule, are created by design, complete with serial and single-production products and carrying out construction, installation, commissioning and commissioning work necessary for putting the NPP into operation;
- 3) in general case AS (AS subsystem) consists of software and hardware (PTK), software and methodological complexes (PMK) and components of technical, software and information support.
The components of these types of support, as well as PMC and PTK, must be manufactured and supplied as products for industrial and technical purposes.
Components can be included in the AS as independent parts or can be combined into complexes; - 4) the creation of AS in organizations (enterprises) requires special training users and system maintenance personnel;
- 5) the functioning of AS and complexes is ensured by a set of organizational and methodological documents, considered during the creation process as components of legal, methodological, linguistic, mathematical, organizational and other types of support. Individual solutions obtained in the process of developing these software can be implemented in the form of components of hardware, software or information support;
- 6) joint functioning and interaction various systems and complexes is carried out on the basis local networks COMPUTER.
Specifications and agreements adopted for local computer networks are mandatory to ensure compatibility of systems, complexes and components.
2. Interrelation of CEN AS with other systems and sets of standards
2.1. Standardization in the field of AS is an integral part of work on the general problem of “Information technology”.
2.2. A unified set of standards for governing documents for automated systems, together with other systems and sets of standards, should form a complete regulatory and technical support for the processes of creation and operation of automated systems.
2.3. CEN AU should cover areas of standardization specific to automated systems and extend traditional areas of standardization to software and hardware, software and methodological complexes and automated systems in general.
2.4. The directions and tasks of standardization in the regulatory and technical support of the processes of creation and operation of nuclear power plants are grouped as follows:
- 1) establishment of technical requirements for products;
- 2) regulation of test methods and rules for certification and certification of products;
- 3) regulation of the rules and procedure for development;
- 4) establishing documentation rules;
- 5) ensuring compatibility;
- 6) regulation of organizational and methodological issues of systems functioning.
Directions 1-4 are traditional in the development, manufacture and supply of products. Directions 5, 6 are specific and arise from the features inherent in the AS.
2.5. The provision of nuclear power plants as a whole and their components with regulatory and technical documentation within the framework of accepted directions and tasks of standardization is different.
Components of hardware, software and information support, as products for industrial and technical purposes, are considered, respectively, as design, software and information products. These products are subject to the current sets of standards ESKD, SRPP, ESPD, SGIP, USD, classifiers and codifiers of technical and economic information, sets of standards such as “OTT”, “Test Methods”, “TU”, as well as the customer’s OTT.
2.5.1. All life cycle design products are fully provided with regulatory and technical documentation valid in mechanical engineering and instrument making.
2.5.2. Software products are provided with scientific and technical documentation included in the ESPD and OTT of the customer. However, the scope of these technical documentation should be expanded to reflect issues related to the development, creation, distribution and operation of software products.
2.5.3. Information products are currently not provided with technical documentation, although individual issues worked out within the framework of USD, classifiers and codifiers of technical and economic information.
2.6. Software-hardware and software-methodological complexes are considered as complex products that have no analogues in mechanical engineering. Considering the status of PTC and PMK as products for industrial and technical purposes, the rules and procedure for their development should be similar to the requirements established by the standards of the system for the development and production of products (SRPP).
