ტექნიკური დოკუმენტაცია. ტექნიკური პროექტის განმარტებითი ჩანაწერი ტექნიკური სპეციფიკაციის მაგალითის განმარტებითი ჩანაწერი

განმარტებითი ჩანაწერის დოკუმენტის მთავარი მიზანია სისტემის შესახებ ზოგადი ინფორმაციის მიწოდება და მისი შემუშავებისას მიღებული ტექნიკური გადაწყვეტილებების დასაბუთება. აქედან გამომდინარე, განმარტებითი ბარათის შემუშავების საფუძველი ძირითადად იქნება სამუშაო პირობები.

ახსნა-განმარტება ტექნიკური პროექტის ერთ-ერთი ყველაზე მნიშვნელოვანი დოკუმენტია. ტექნიკური დიზაინი შემუშავებულია საბოლოო ტექნიკური გადაწყვეტილებების იდენტიფიცირების მიზნით, რომელიც უზრუნველყოფს პროდუქტის დიზაინის სრულ სურათს.
განმარტებითი ჩანაწერის შესაქმნელად პროგრამის შემუშავებისას რეკომენდებულია გამოიყენოთ GOST 19.404-79 „ახსნა-განმარტება. მოთხოვნები შინაარსისა და დიზაინის მიმართ“.

ტექნიკური პროექტისთვის ახსნა-განმარტების შესაქმნელად, რომელიც აღწერს ავტომატურ სისტემას (AS), რეკომენდებულია სტანდარტული RD 50-34.698-90 „ავტომატური სისტემების“ გამოყენება. მოთხოვნები დოკუმენტების შინაარსთან დაკავშირებით“.

ზემოაღნიშნული დოკუმენტების მრავალი განყოფილება ერთმანეთს ემთხვევა, ასე რომ, მაგალითად, განვიხილავთ RD 50-34.698-90-ის საფუძველზე შექმნილ დოკუმენტს განმარტებითი შენიშვნა.

1. ზოგადი დებულებები

1.1 შექმნილი სპიკერის დასახელება

განმარტებითი ჩანაწერის დოკუმენტის ეს ნაწილი შეიცავს AS-ის სრულ და მოკლე სახელს.

მაგალითად: „ამ დოკუმენტში შექმნილ სისტემას ეწოდება კორპორატიული ინფორმაციის პორტალი. ასევე ნებადართულია შემოკლებული სახელის „KIP“ ან „სისტემის“ გამოყენება.

1.2 დოკუმენტები, რომლებზედაც შექმნილია სისტემა

განმარტებითი ჩანაწერის დოკუმენტის ამ ნაწილში მითითებული უნდა იყოს მითითებები ხელშეკრულებაზე და ავტომატური სისტემის შემუშავების სამუშაო პირობებზე.

1.3 ორგანიზაციები, რომლებიც მონაწილეობენ სისტემის განვითარებაში

განმარტებითი ჩანაწერის დოკუმენტის ამ განყოფილებაში მითითებულია მომხმარებლის და დეველოპერი ორგანიზაციების სახელები.

1.4 AS-ის განვითარების მიზნები

განმარტებითი ჩანაწერის დოკუმენტის ამ ნაწილში უნდა იყოს მითითებული ტექნიკური, ეკონომიკური და საწარმოო სარგებელი, რომელსაც მომხმარებელი მიიღებს შემუშავებული სისტემის დანერგვის შემდეგ.

მაგალითად: „შექმნილი სისტემის მიზანია:

• კომპანიის საბუთების ნაკადის ოპტიმიზაცია;
• კომპანიის კორპორატიული კულტურის მხარდაჭერა;
• კომპანიის თანამშრომლებს შორის კომუნიკაციის ოპტიმიზაცია. »

1.5 განვითარებული დინამიკის სისტემის დანიშნულება და გამოყენების ფარგლები

განმარტებითი ჩანაწერის დოკუმენტის ეს განყოფილება უნდა მოიცავდეს ავტომატიზირებული საქმიანობის ტიპის აღწერას და იმ პროცესების ჩამონათვალს, რომლებისთვისაც სისტემა განკუთვნილია ავტომატიზაციისთვის.

მაგალითად: „KIP შექმნილია სრული და დროული ინფორმაციის მიწოდებისთვის, ასევე თანამშრომლების მუშაობის ეფექტური ორგანიზებისთვის. სისტემამ უნდა უზრუნველყოს თანამშრომლების ერთობლივი მუშაობის ორგანიზება შემდეგი შესაძლებლობების გამოყენებით:

• კონფერენციების შექმნა საკითხების განსახილველად;
• ელექტრონული ფოსტის შეტყობინებების გაგზავნა/მიღება;
• დოკუმენტებზე თანამშრომლობის უზრუნველყოფა;
• დოკუმენტების კოორდინაცია;
• შემოსული და გამავალი დოკუმენტაციის აღრიცხვის წარმოება.“.

1.6 ინფორმაცია დიზაინში გამოყენებული მარეგულირებელი და ტექნიკური დოკუმენტების შესახებ

ამ განყოფილებაში უნდა იყოს მითითებული სტანდარტები, რომლებიც გამოყენებული იქნა განმარტებითი ჩანაწერის დოკუმენტის შესაქმნელად.

მაგალითად: „პროექტის დროს გამოყენებული იქნა შემდეგი მარეგულირებელი და ტექნიკური დოკუმენტები:

• GOST 34.201-89 ”ინფორმაციული ტექნოლოგია. სტანდარტების ნაკრები ავტომატური სისტემებისთვის. დოკუმენტების ტიპები, სისრულე და აღნიშვნები ავტომატური სისტემების შექმნისას“;
• GOST 34.602-89 ”ინფორმაციული ტექნოლოგია. სტანდარტების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემის შექმნის ტექნიკური მახასიათებლები“;
• GOST 34.003-90 ”ინფორმაციული ტექნოლოგია. სტანდარტების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემები. ტერმინები და განმარტებები“;
• GOST 34.601-90 ”ინფორმაციული ტექნოლოგია. სტანდარტების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემები. შექმნის ეტაპები“;
• RD 50-682-89 „მეთოდური ინსტრუქციები. Საინფორმაციო ტექნოლოგია. სტანდარტებისა და გაიდლაინების ნაკრები ავტომატური სისტემებისთვის. ზოგადი დებულებები“;
• RD 50-680-88 „მეთოდური ინსტრუქციები. ავტომატური სისტემები. ძირითადი დებულებები“;
• RD 50-34.698-90 „მეთოდური ინსტრუქციები. Საინფორმაციო ტექნოლოგია. სტანდარტებისა და გაიდლაინების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემები. მოთხოვნები დოკუმენტების შინაარსთან დაკავშირებით“.

1.7. სისტემის შექმნის თანმიმდევრობა

რამდენიმე განმეორებით შექმნილი სისტემებისთვის, განმარტებით ჩანაწერში უნდა იყოს მითითებული თითოეული გამეორების სამუშაოს მოცულობა. ცალკე, აუცილებელია გამოვყოთ ამ გამეორებისთვის დაგეგმილი სამუშაო.

მაგალითად: „კორპორატიული საინფორმაციო პორტალის პროექტის განხორციელება დაგეგმილია ორ ეტაპად.

ინსტრუმენტაციის პირველი ეტაპი მოიცავს კომპანიის თანამშრომლების ერთობლივი მუშაობის ორგანიზებას ისეთი შესაძლებლობების დანერგვის გამო, როგორიცაა:

• Მესინჯერი;
• კონფერენციის ორგანიზება;
• ელექტრონული ფოსტის გაგზავნა/მიღება;
• დოკუმენტების კოორდინაცია სისტემის გამოყენებით“.

2 აქტივობის პროცესის აღწერა

განმარტებითი ჩანაწერის დოკუმენტის ეს ნაწილი უნდა ასახავდეს სისტემის მიერ ავტომატიზირებულ პროცესებსა და ფუნქციებს მთელი ბიზნეს პროცესის განმავლობაში.

განმარტებით ჩანაწერში მასალის საილუსტრაციოდ, ნებადართულია UML, ARIS ან IDF0 აღნიშვნების გამოყენება, აგრეთვე სტანდარტული აპლიკაციების (Visio) გამოყენებით შექმნილი სქემატური სურათები.

განმარტებითი ჩანაწერის დოკუმენტში ავტომატიზებულ და არაავტომატიზირებულ ფუნქციებს შორის ურთიერთობის გასაგებად, აუცილებელია მკაფიოდ განვასხვავოთ მომხმარებლის ქმედებები და სისტემის მოქმედებები.

მაგალითად: „1. მომხმარებელი ქმნის დოკუმენტს

• მომხმარებელი იწყებს დოკუმენტის დასამტკიცებლად წარდგენის პროცესს
• სისტემა ცვლის დოკუმენტის სტატუსს „დამტკიცებისთვის“. »
• ძირითადი ტექნიკური გადაწყვეტილებები

2.1. გადაწყვეტილებები სისტემის სტრუქტურისა და ქვესისტემების შესახებ.

დოკუმენტის განმარტებითი ჩანაწერის ეს ნაწილი იძლევა გადაწყვეტილებებს სისტემის და მისი ქვესისტემების ფუნქციონალური სტრუქტურის შესახებ.

2.2. სისტემის კომპონენტებს შორის ურთიერთქმედების საშუალებები და მეთოდები. ურთიერთკავშირი გარე სისტემებთან

განმარტებითი ჩანაწერის დოკუმენტის ამ განყოფილებაში აუცილებელია მიუთითოთ იმ სისტემების სია, რომლებთანაც შექმნილი პროდუქტი უნდა ურთიერთობდეს. განმარტებით ჩანაწერში სისტემის კომპონენტების ურთიერთქმედების აღწერისას აუცილებელია მონაცემთა გაცვლის ფორმატის მითითება.

მაგალითად: ”ინსტრუმენტული და გარე სისტემების ურთიერთქმედების ფარგლებში გამოიყენება შემდეგი ტექნოლოგიები:
- "საწარმოთა აღრიცხვა" - ფაილების გაცვლა დადგენილ XML/Excel ფორმატში."

2.3. გადაწყვეტილებები მუშაობის რეჟიმებზე

განმარტებითი ჩანაწერის დოკუმენტის ეს ნაწილი მოიცავს სისტემის მუშაობის რეჟიმების ჩამონათვალს და აღწერას. ჩვეულებრივ განასხვავებენ შემდეგ რეჟიმებს: ნორმალური რეჟიმი, სატესტო ოპერაციის რეჟიმი, მომსახურების რეჟიმი. განმარტებით ბარათში უნდა იყოს აღწერილი როგორც თავად რეჟიმი, ასევე ის შემთხვევები, როდესაც ის შემოღებულია.

2.4. გადაწყვეტილებები ატომური ელექტროსადგურის პერსონალის რაოდენობის, კვალიფიკაციისა და ფუნქციების შესახებ

დოკუმენტის განმარტებითი ჩანაწერის ეს ნაწილი არეგულირებს ტექნიკური და ფუნქციონალური პერსონალის საქმიანობას. ახსნა-განმარტებაში მითითებული უნდა იყოს თანამშრომელთა კატეგორია, რომელიც მიეკუთვნება პერსონალის კონკრეტულ ტიპს და აღწერს მათ ფუნქციებს სისტემის ფარგლებში.

მაგალითად: „პორტალის ადმინისტრატორი პასუხისმგებელია:

• მონაცემთა ბაზისა და პროგრამული უზრუნველყოფის მთლიანობა;
• პრევენციული ღონისძიებები მონაცემთა უსაფრთხოების უზრუნველსაყოფად;
• წვდომის უფლებების განაწილება და მომხმარებელთა სისტემაში რეგისტრაცია. »

2.5. ტექნიკური მახასიათებლებით განსაზღვრული სისტემის სამომხმარებლო მახასიათებლების უზრუნველყოფა

განმარტებითი ჩანაწერის დოკუმენტის ეს განყოფილება შექმნილია ტექნიკური მახასიათებლებით განსაზღვრული პროდუქტის ხარისხის მოთხოვნების საფუძველზე. აქ აუცილებელია აღვწეროთ ის პარამეტრი, რომლითაც განისაზღვრება სისტემის ხარისხი. განმარტებით ჩანაწერში ასევე მითითებულია გადაწყვეტილებები, რომლებითაც ეს მახასიათებელი იქნა მიღწეული სისტემაში.

მაგალითად: „ინსტრუმენტული პროგრამული უზრუნველყოფის მოდულების შეცდომების ტოლერანტობა და ფუნქციონირება უზრუნველყოფილია სამრეწველო პროგრამული პლატფორმების გამოყენებით IBM WebSphere Portal, Enterprise Oracle 10g“.

2.6. ფუნქციების შემადგენლობა და სისტემის მიერ განხორციელებული ამოცანების ნაკრები

განმარტებითი ჩანაწერის დოკუმენტის ეს ნაწილი შეიცავს ამოცანების ჩამონათვალს, რომლებსაც სისტემა წყვეტს. განმარტებით ჩანაწერში ფუნქციები და დავალებების ნაკრები შეიძლება წარმოდგენილი იყოს უნომრო სიის სახით.

2.7. გადაწყვეტილებები ტექნიკური აღჭურვილობის კომპლექტზე და მის ადგილზე განთავსებაზე

განმარტებითი ჩანაწერის დოკუმენტის ეს განყოფილება შეიცავს გადაწყვეტილებებს სისტემის ტექნიკური არქიტექტურის შესახებ და მოთხოვნები ტექნიკური საშუალებების ნაკრების მიმართ, რომელიც აუცილებელია მისი სწორი ფუნქციონირების უზრუნველსაყოფად.

რეკომენდირებულია ტექნიკური საშუალებების ნაკრების მოთხოვნები განთავსდეს განმარტებით ჩანაწერში ცხრილის სახით.
Მაგალითად: "

აღჭურვილობა	ტექნიკური მახასიათებლები
მონაცემთა ბაზის სერვერი
თაროებზე დამაგრების ვერსია	არაუმეტეს 4U
პროცესორის არქიტექტურა	RISC (64-ბიტიანი)
CPU სიხშირე	მინიმუმ 1.5 გჰც
CPU ქეში	მინიმუმ 1 მბ
OS	Windows 2003 SP2
დაინსტალირებული პროცესორების შესაძლო რაოდენობა	მინიმუმ 4
დაინსტალირებული პროცესორების რაოდენობა
RAM-ის შესაძლო მოცულობა	32 GB ECC-ით
ოპერატიული მეხსიერების მოცულობა	მინიმუმ 8 GB
ინტერფეისების ხელმისაწვდომობა	10/100/1000 Base-T Ethernet ინტერფეისები 2 ც.; Ultra320 SCSI 2 ც.; USB 4 ცალი; სერიული ინტერფეისი 1 ც.; PCI 64-ბიტიანი გაფართოების სლოტები 6 ცალი.
ვიდეო კარტა:	მინიმუმ 8 მბ.
დაინსტალირებული მყარი დისკების შესაძლო რაოდენობა	მინიმუმ 4
დაინსტალირებული დისკების რაოდენობა
მკითხველი
Ენერგიის წყარო	შეყვანის პარამეტრები: 200-240 ვ, დენის სიხშირე: 50-60 ჰც; მაქსიმალური შეყვანის სიმძლავრე არაუმეტეს 1600 W; მინიმუმ 2 დენის წყარო, რომელიც უზრუნველყოფს ხარვეზების ტოლერანტობას.

»

განმარტებით ჩანაწერში ტექნიკური საშუალებების კომპლექსის ობიექტების განლაგების აღწერისას აუცილებელია იხელმძღვანელოთ SNiP 11-2-80-ის მოთხოვნებით "B" კატეგორიის შენობებისთვის.

2.8. მოცულობა, შემადგენლობა, ორგანიზების მეთოდები, ინფორმაციის დამუშავების თანმიმდევრობა

საინფორმაციო მხარდაჭერა მოიცავს მანქანურ და დამატებით მანქანურ ინფორმაციას. შიდა საინფორმაციო მხარდაჭერას უზრუნველყოფს მონაცემთა ბაზა (DB), შეყვანის და გამომავალი დოკუმენტები, რომლებიც მოდის გარე სისტემებიდან.

ავტომატური საინფორმაციო ბაზა იქმნება ქაღალდის დოკუმენტებში მოცემული მონაცემებით. ხშირად, ავტომატური სისტემების შემუშავებისას, გამოიყენება მხოლოდ მანქანაში არსებული ინფორმაციის ბაზა, ამიტომ განმარტებითი შენიშვნის დოკუმენტში მთავარი აქცენტი უნდა გაკეთდეს ამ განყოფილების შინაარსზე.

განმარტებითი ჩანაწერის დოკუმენტში შიდა საინფორმაციო ბაზის აღწერისას აუცილებელია ყველა ქვესისტემისთვის და გარე სისტემისთვის შემავალი და გამომავალი დოკუმენტების და შეტყობინებების მითითება.

მაგალითად: „ელექტრონული დოკუმენტების მართვის ქვესისტემისთვის შეყვანილი ინფორმაციაა:

• წარმოების სამუშაო პროცესის დოკუმენტების ელექტრონული ვერსიები;
• ელექტრონული ციფრული ხელმოწერა;

ელექტრონული დოკუმენტების მართვის ქვესისტემისთვის გამომავალი ინფორმაციაა:

• დოკუმენტის სასიცოცხლო ციკლის ისტორიის ჟურნალი;
• დოკუმენტის დამტკიცების ისტორიის ჟურნალი;
• დოკუმენტის ელექტრონული ვერსიის ფაილი RTF ფორმატში. »

2.9. პროგრამული პროდუქტების შემადგენლობა, ოპერაციული ენები, პროცედურების და ოპერაციების ალგორითმები და მათი განხორციელების მეთოდები

განმარტებითი ჩანაწერის დოკუმენტის ეს ნაწილი უნდა ითვალისწინებდეს სისტემის განვითარების ტექნოლოგიებსა და საშუალებებს.

Მაგალითად:
«

• მონაცემთა ბაზის სერვერი: Oracle 10g
• პორტალი: Websphere Portal Extend v6.0.
• ბიზნეს მოდელირება: ARIS

»

3 ღონისძიებები ავტომატიზაციის ობიექტის მოსამზადებლად სისტემის ამოქმედებისთვის

განმარტებითი ჩანაწერის დოკუმენტის ეს ნაწილი აღწერს შემდეგ აქტივობებს:

• ღონისძიებები ინფორმაციის კომპიუტერული დამუშავებისთვის შესაფერის ფორმაში მოყვანის მიზნით;
• პერსონალის კვალიფიკაციის მომზადებისა და ტესტირების ღონისძიებები;
• ღონისძიებები საჭირო ერთეულებისა და სამუშაო ადგილების შესაქმნელად;
• ზომები ავტომატიზაციის ობიექტის შეცვლისთვის;
• სხვა აქტივობები შექმნილი სისტემების სპეციფიკურ მახასიათებლებზე დაყრდნობით

27.10.2016 09:57:23

ეს სტატია განიხილავს ტექნიკური პროექტის ეტაპს, რომელიც ეხება ინფორმაციული უსაფრთხოების სისტემის (ISS) სასიცოცხლო ციკლის ერთ-ერთ ეტაპს - "დიზაინის" ეტაპს, რომელიც, GOST 34.601-90 შიდა სტანდარტის შესაბამისად, დაუყოვნებლივ მოჰყვება განვითარებას. ინფორმაციული უსაფრთხოების სისტემის სამუშაო პირობები.

1. NIB-ის ტექნიკური საპროექტო დოკუმენტაციის შემუშავება

ინფორმაციული უსაფრთხოების სისტემის (შემდგომში ISS) სასიცოცხლო ციკლი ზოგადად შედგება შემდეგი ეტაპებისაგან:

• ინფორმაციული უსაფრთხოების სისტემების მოთხოვნების ანალიზი;
• დიზაინი;
• განხორციელება;
• განხორციელება;
• ექსპლუატაცია.

ეს სტატია განიხილავს ტექნიკური პროექტის ეტაპს, რომელიც მიეკუთვნება "დიზაინის" ეტაპს და, შიდა სტანდარტის GOST 34.601-90 შესაბამისად, დაუყოვნებლივ მოჰყვება ინფორმაციული უსაფრთხოების სისტემის ტექნიკური მახასიათებლების შემუშავებას.

1.1. რატომ შეიმუშავეთ დოკუმენტაცია NIB-ისთვის?

ამ კითხვაზე პასუხი უნდა განიხილებოდეს ორ პლანზე: ინფორმაციული რესურსების მფლობელის სიბრტყეში (რომლის დასაცავად იქმნება ინფორმაციული უსაფრთხოების სისტემა) და ინფორმაციული უსაფრთხოების სისტემის უშუალო შემქმნელის სიბრტყეში.

საინფორმაციო რესურსების მფლობელისთვის მნიშვნელოვანია შედეგის მიღება მოქმედი ინფორმაციული უსაფრთხოების სისტემის სახით, რომელიც ამცირებს ორგანიზაციაში შეზღუდული წვდომის ინფორმაციის კომპრომეტირების რისკებს. ტექნიკური პროექტი ამ შემთხვევაში ემსახურება მომავალი სისტემის ფუნდამენტური პრინციპების შემუშავებას, კერძოდ, მოიცავს აღწერას, თუ როგორ აშენდება და იფუნქციონირებს ISS, რა ზომები და საშუალებები უზრუნველყოფს ინფორმაციის დაცვას, რა არის განვითარებისა და გაუმჯობესების შესაძლებლობები. სისტემა. ინფორმაციული უსაფრთხოების სისტემის ტექნიკური პროექტის შემუშავების დასრულების შემდეგ, მომხმარებელი იღებს ინფორმაციული უსაფრთხოების სისტემის დოკუმენტაციის ყოვლისმომცველ კომპლექტს, რომელიც აღწერს მომავალი სისტემის ყველა ტექნიკურ ნიუანსს.

უშუალო შემსრულებლისთვის ტექნიკური პროექტის ეტაპზე აუცილებელია ISS-ის ყველაზე შესაფერისი არქიტექტურის დადგენა, ასევე ორგანიზაციაში ინფორმაციის დაცვის ზომებისა და საშუალებების სწორი არჩევანის გაკეთება. ასევე მნიშვნელოვანია სისტემის მახასიათებლებისა და თვისებების ტექნიკურ მახასიათებლებთან შესაბამისობის უზრუნველყოფა, ან დამკვეთის მონაწილეობითა და თანხმობით, ტექნიკურ მახასიათებლებში მითითებული მოთხოვნების კორექტირების დასაბუთება ეფექტურობის გაზრდის მიზნით. სისტემა, რომელიც იქმნება.

ამრიგად, ტექნიკური საპროექტო დოკუმენტაციის შემუშავების შედეგად, მომხმარებელს ექნება პასუხები შემდეგ კითხვებზე:

• როგორია NIB-ის ზოგადი არქიტექტურა;
• რა ღონისძიებები და საშუალებები იქნება გამოყენებული ინფორმაციის დაცვის მოთხოვნების განსახორციელებლად;
• როგორ იმუშავებს NIB;
• რა ცვლილებები მოჰყვება ორგანიზაციაში ინფორმაციული უსაფრთხოების დონის ასამაღლებლად საჭირო ცვლილებებს ISS-ის დანერგვის შედეგად;
• იქნება თუ არა გათვალისწინებული მომხმარებლის მოთხოვნები (ბიზნეს მოთხოვნები) და ინფორმაციული უსაფრთხოების სფეროში მარეგულირებელი სამართლებრივი აქტების მოთხოვნები ინფორმაციული უსაფრთხოების სისტემის შემუშავებისა და დანერგვისას და თუ ასეა, როგორ.

ტექნიკური საპროექტო დოკუმენტაციის შემუშავების პროცესში კონტრაქტორი მიიღებს შემდეგ შედეგებს:

• ISS-ის მშენებლობის შემდეგ ეტაპებზე გადასვლის საფუძველი, კერძოდ, სამუშაო დოკუმენტაციისა და განხორციელების ეტაპები;
• გამოყენებული არქიტექტურის, ტექნოლოგიებისა და ხელსაწყოების გააზრება, სისტემის აგების წესი;
• როგორ არის დანერგილი მომხმარებლის მოთხოვნები (ბიზნეს მოთხოვნები) და მარეგულირებელი დოკუმენტები ინფორმაციული უსაფრთხოების სფეროში.

1.2. ტექნიკური საპროექტო დოკუმენტაციის შემუშავების მიდგომების მიმოხილვა

ინფორმაციული უსაფრთხოების სისტემის ტექნიკური პროექტის შემუშავება ყველაზე ხშირად შესაბამისი სტანდარტებისა და სახელმძღვანელო დოკუმენტების საფუძველზე ხორციელდება. უფრო მეტიც, მათი გამოყენება სავალდებულოა სამთავრობო დაწესებულებებისთვის, მაგრამ რეკომენდებულია კომერციული. პრაქტიკაში, კომერციული ორგანიზაციები ასევე იყენებენ სახელმწიფო სტანდარტებს ტექნიკური საპროექტო დოკუმენტაციის შემუშავებისას შემდეგი მიზეზების გამო:

• არაერთხელ აპრობირებული მიდგომა საინფორმაციო სისტემების შესაქმნელად;
• დოკუმენტების გააზრებული სტრუქტურა და შინაარსი;
• დოკუმენტების ნაკრები, რომელიც საკმარისია თითქმის ნებისმიერი სისტემის შემუშავებისა და აღწერისთვის.

NIB-ის ტექნიკური პროექტის (TP) ეტაპისთვის დოკუმენტაციის შემუშავებისთვის გამოიყენება 34 სერიის სახელმწიფო სტანდარტები და სახელმძღვანელო დოკუმენტები:

• GOST 34.201-89 "დოკუმენტების ტიპები, სისრულე და აღნიშვნა ავტომატური სისტემების შექმნისას." ეს სტანდარტი განსაზღვრავს:
  • დოკუმენტების ტიპები და სახელები TP ეტაპზე;
  • დოკუმენტაციის სისრულე;
  • მიღებული დოკუმენტების აღნიშვნები;
  • NIB და მათი ნაწილების აღნიშვნის წესები.
• GOST 34.003-90 "ტერმინები და განმარტებები";
• GOST 34.601-90 ”ავტომატური სისტემები. შექმნის ეტაპები“. სტანდარტი განსაზღვრავს:
  • ტექნიკურ ეტაპზე განხორციელებული სამუშაოების ეტაპების ჩამონათვალი;
  • ტექნიკურ ეტაპზე შესრულებული სამუშაოს დეტალური აღწერა;
  • ISS-ის შექმნაში მონაწილე ორგანიზაციების სია;
• RD 50-34.698-90 „ავტომატური სისტემები. მოთხოვნები დოკუმენტების შინაარსთან დაკავშირებით“. ეს სახელმძღვანელო დოკუმენტი განსაზღვრავს TC ეტაპზე დოკუმენტების შინაარსის მოთხოვნებს.

მნიშვნელოვანია გვესმოდეს, რომ სტანდარტების 34 სერიის მიხედვით, ტექნიკური დიზაინი არის სისტემის შექმნის ეტაპი და არა მხოლოდ დოკუმენტების ნაკრები. პრაქტიკაში, ეს ეტაპი ხშირად შერწყმულია წინასწარი დიზაინის ეტაპთან, რომელიც ემსახურება რამდენიმე წინასწარი გადაწყვეტის შემუშავებას და ყველაზე შესაფერისის დასაბუთებას. ასეთი კომბინაცია დაშვებულია სტანდარტით, მაგრამ გასათვალისწინებელია, რომ ეს არ უარყოფს წინასწარი დიზაინის ეტაპის მიზნების მიღწევის აუცილებლობას.

ყველაზე ხშირად, წინასწარი დიზაინის ეტაპი ვითარდება იმ შემთხვევაში, როდესაც სისტემის ტექნიკური მახასიათებლების მოთხოვნები შეიძლება განხორციელდეს რამდენიმე ფუნდამენტურად განსხვავებული გზით, და ასევე იმ შემთხვევაში, როდესაც ამ მეთოდებს შორის არ არის აშკარად სასურველი.

თუმცა, აღსანიშნავია, რომ ზემოაღნიშნული სტანდარტები ძალიან ზოგადია და ძირითადად ახორციელებს საპროექტო და ზოგად სტრუქტურულ ფუნქციებს. ტექნიკური პროექტის ეტაპის დოკუმენტების არსებითი ნაწილის შესაქმნელად, დიზაინერები იყენებენ ინფორმაციას შემდეგი წყაროებიდან:

მოქმედი მარეგულირებელი დოკუმენტები (RLA), რომლებიც არეგულირებს გარკვეული შეზღუდული წვდომის ინფორმაციის დაცვის მოთხოვნებს. ეს რეგულაციები წარმოადგენს მოთხოვნებს საინფორმაციო სისტემებში ინფორმაციის დაცვის ზომების შესახებ, აღწერს ამ ღონისძიებების განხორციელების ნიუანსებს და დამატებით გამაძლიერებელ ზომებს. მოქმედ სამართლებრივ აქტებს შორისაა შემდეგი:

• რუსეთის FSTEC-ის 2013 წლის 18 თებერვლის ბრძანება No21 „ორგანიზაციული და ტექნიკური ღონისძიებების შემადგენლობისა და შინაარსის დამტკიცების შესახებ პერსონალური მონაცემების უსაფრთხოების უზრუნველსაყოფად პერსონალური მონაცემების საინფორმაციო სისტემებში მათი დამუშავებისას“;
• რუსეთის FSTEC-ის 2013 წლის 11 თებერვლის ბრძანება No17 „სახელმწიფო საინფორმაციო სისტემებში შემავალი ინფორმაციის დაცვის მოთხოვნების დამტკიცების შესახებ, რომელიც არ წარმოადგენს სახელმწიფო საიდუმლოებას“.
• რუსეთის FSTEC-ის 2014 წლის 14 მარტის ბრძანება No. 31 „ინფორმაციის უსაფრთხოების უზრუნველყოფის მოთხოვნების დამტკიცების შესახებ ავტომატური კონტროლის სისტემებში წარმოებისა და ტექნოლოგიური პროცესების კრიტიკულ ობიექტებში, პოტენციურად სახიფათო ობიექტებში, აგრეთვე ობიექტებში, რომლებიც წარმოადგენენ გაზრდილ საფრთხეს. ადამიანების სიცოცხლე და ჯანმრთელობა და ბუნებრივი გარემო;
• მეთოდოლოგიური დოკუმენტი „ინფორმაციის დაცვის ზომები სახელმწიფო საინფორმაციო სისტემებში“, დამტკიცებული რუსეთის FSTEC-ის მიერ 2014 წლის 11 თებერვალს.

შეზღუდული წვდომის ინფორმაციის დაცვის მოთხოვნები და დამცავი ზომების ჩამონათვალი განსხვავდება უსაფრთხოების სხვადასხვა დონის/კლასის საინფორმაციო სისტემებისთვის. თუ ორგანიზაციაში ინფორმაცია არ არის დაცული რუსეთის ფედერაციის ფედერალური კანონების შესაბამისად (მაგალითად, ოფიციალური საიდუმლოებები), მაშინ ამ ინფორმაციის მფლობელს შეუძლია გამოიყენოს ამ მარეგულირებელ სამართლებრივ აქტებში შემოთავაზებული მიდგომები კორპორატიული ინფორმაციის უსაფრთხოების სისტემის შესაქმნელად. .

რუსული და უცხოური სტანდარტები, რომლებიც აღწერს სხვადასხვა მიდგომას ISS-ის მშენებლობის სასიცოცხლო ციკლის ეტაპების განხორციელების გზებზე, ტექნიკური დიზაინის ეტაპის ჩათვლით:

• სახელმწიფო სტანდარტების სერია GOST R ISO/IEC 2700X, იდენტურია საერთაშორისო სტანდარტების ISO/IEC 2700X. ეს სტანდარტები აღწერს PDCA (დაგეგმე, გააკეთე, შემოწმება, აქტი) პროცესის მიდგომა ინფორმაციული უსაფრთხოების მართვის სისტემის სასიცოცხლო ციკლის განხორციელებისადმი, რომელიც ინფორმაციული უსაფრთხოების სისტემის განუყოფელი ნაწილია;
• NIST SP 800-64 არის აშშ-ს სტანდარტებისა და ტექნოლოგიების ეროვნული ინსტიტუტის სტანდარტი, რომელიც აღწერს საინფორმაციო სისტემების განვითარების სასიცოცხლო ციკლს;
• NIST SP 800-37 არის აშშ-ს სტანდარტებისა და ტექნოლოგიების ეროვნული ინსტიტუტის სტანდარტი, რომელიც ხელმძღვანელობს რისკების მართვის ინტეგრირებისთვის საინფორმაციო სისტემების განვითარების სასიცოცხლო ციკლში.

მწარმოებლის ოპერატიული დოკუმენტაცია ინფორმაციული უსაფრთხოების აღჭურვილობისა და დამხმარე მოწყობილობებისთვის. ეს დოკუმენტები შეიცავს ყოვლისმომცველ ტექნიკურ ინფორმაციას ინფორმაციული უსაფრთხოების სისტემების მშენებლობაში გამოყენებული ინსტრუმენტების შესახებ, მათ შორის უშუალოდ დაკავშირებული ინფორმაციული უსაფრთხოების ზომების განხორციელებასთან, რომლებიც არ არის დაკავშირებული, მაგალითად, სერვერებთან, მონაცემთა შენახვის სისტემებთან, ვირტუალიზაციის ინსტრუმენტებთან და სხვა. ასეთი დოკუმენტების საერთო ნაკრები განსხვავდება მწარმოებლისგან მწარმოებელზე და დამოკიდებულია, სხვა საკითხებთან ერთად, კონკრეტული ხელსაწყოს (ტექნიკის/პროგრამული უზრუნველყოფის) განხორციელებაზე. ქვემოთ მოცემულია ოპერატიული დოკუმენტაციის სტანდარტული ნაკრები ინფორმაციული უსაფრთხოების ინსტრუმენტებისთვის, რომლებიც გამოიყენება დოკუმენტების შემუშავებისთვის ტექნიკური პროექტის ეტაპზე:

• ზოგადი აღწერა (მონაცემთა ცხრილი);
• ადმინისტრატორის სახელმძღვანელო (შეიძლება მოიცავდეს ადგილობრივ და ცენტრალიზებულ მენეჯმენტის სახელმძღვანელოს);
• მომხმარებლის სახელმძღვანელო;
• სწრაფი ინსტალაციისა და განლაგების სახელმძღვანელო (ტექნიკის ინფორმაციის დაცვის სისტემებისთვის);
• ოპერატორის სახელმძღვანელო;
• ვირტუალურ ინფრასტრუქტურაში განლაგების სახელმძღვანელო (პროგრამული ინფორმაციის უსაფრთხოების სისტემებისთვის);

ზოგადი ინფორმაცია ხელმისაწვდომი ISS არქიტექტურების შესახებ, საუკეთესო პრაქტიკა ISS-ის აგების თვალსაზრისით, ინსტრუქციები უსაფრთხოებისა და ინფორმაციული უსაფრთხოების სისტემების ერთმანეთთან ინტეგრაციის შესახებ, ინფორმაცია გარკვეული ინფორმაციული უსაფრთხოების სისტემების ურთიერთქმედების პრობლემების შესახებ. ასეთი ინფორმაციის მაგალითები შეიძლება შეიცავდეს შემდეგ დოკუმენტებს:

• ინფორმაციული უსაფრთხოების სისტემების არქიტექტურის სახელმძღვანელოები, მაგალითად: Defense-in-Depth, Cisco SAFE, Check Point SDP და სხვა;
• საუკეთესო პრაქტიკა ინფორმაციის უსაფრთხოების სფეროში, მაგალითად, ხელმისაწვდომია ამ ბმულებზე (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/ 800-14 /800-14.pdf). ეს დოკუმენტები ყველაზე ხშირად წარმოდგენილია ინგლისურ ენაზე, თუმცა, დამცავი აღჭურვილობის ნებისმიერ რუს მწარმოებელს აქვს საკუთარი საუკეთესო პრაქტიკა უსაფრთხოების ზომების განსახორციელებლად და შეუძლია მათი მოთხოვნის შემთხვევაში;
• უსაფრთხოების სახელმძღვანელო ინფორმაციული უსაფრთხოებისა და ოპერაციული გარემოსთვის. ამის მაგალითია "უსაფრთხოების" განყოფილება Microsoft-ის ოფიციალურ პორტალზე (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. ტექნიკური პროექტის შემუშავება NIB-ისთვის GOST 34-ის შესაბამისად

ISS-სთვის ტექნიკური პროექტის ეტაპზე დოკუმენტების შემუშავება ყველაზე ხშირად ხორციელდება ამ სერვისების ინტეგრატორების მიერ და ხორციელდება ძირითადად შემდეგი გეგმის შესაბამისად:

შესამუშავებელი დოკუმენტების ჩამონათვალის განსაზღვრა - ეს ინფორმაცია მითითებულია ISS-ის ტექნიკურ მახასიათებლებში. ზოგიერთ შემთხვევაში, დოკუმენტის შემქმნელმა, მომხმარებელთან შეთანხმებით, შეიძლება გააფართოვოს ან შეამციროს ეს სია, თუ ეს შესაძლებლობა არის გათვალისწინებული ტექნიკური მახასიათებლებით;

დოკუმენტის შაბლონების შემუშავება TP ეტაპისთვის - სტრუქტურა გამოიყენება RD 50-34.698-90 და GOST 2.106 (ზოგიერთი დოკუმენტისთვის), ფორმატირებული GOST 2.105-95 შესაბამისად;

დოკუმენტების არსებითი ნაწილის შემუშავება. სისტემის მოთხოვნები დადგენილია NIB-ის ტექნიკურ მახასიათებლებში. ამ მოთხოვნების შესაბამისად დგინდება სისტემაში განსახორციელებლად საჭირო დამცავი ტექნიკური და ორგანიზაციული ღონისძიებების ნუსხა. დაცვის ზომები შეიძლება განისაზღვროს შესაბამის რეგულაციებში (დამოკიდებულია დაცული ინფორმაციის ტიპზე), კორპორატიულ სტანდარტებსა და ინფორმაციული უსაფრთხოების პოლიტიკაში, ასევე ორგანიზაციის საფრთხის მოდელის შემუშავებისას გამოვლენილი უსაფრთხოების მიმდინარე საფრთხეების არსებობის საფუძველზე. დამცავი ღონისძიებების ჩამონათვალის საფუძველზე IS-ის შემქმნელი ირჩევს ინფორმაციული უსაფრთხოების შესაბამის ინსტრუმენტებს და ავითარებს ინფორმაციული უსაფრთხოების სისტემის ფუნქციურ სტრუქტურას (ქვესისტემები, კომპონენტები). გარდა ამისა, ტექნიკური დიზაინის დოკუმენტები აღწერს დაცვის ღონისძიებების პრაქტიკულ განხორციელებას, რომელიც ეფუძნება შერჩეულ უსაფრთხოების დაცვას ან ორგანიზაციულ ღონისძიებებს ორგანიზაციის ინფრასტრუქტურაში.

შემუშავებული დოკუმენტაციისა და მასში წარმოდგენილი გადაწყვეტილებების კოორდინაცია სისტემის მომხმარებელთან.

ტექნიკური პროექტის დოკუმენტაციის შემუშავებისას, ყველაზე ხშირად არ არის საჭირო GOST 34.201-89-ში მითითებული დოკუმენტების სრული ჩამონათვალის შემუშავება, რადგან ეს სტანდარტი მოძველებულია და ზოგიერთი დოკუმენტი არ ითვალისწინებს თანამედროვე საინფორმაციო სისტემების განვითარების ტენდენციებსა და ტექნოლოგიებს. . ინფორმაციული უსაფრთხოების სისტემის აღწერისთვის საჭირო დოკუმენტების მინიმალური ნაკრები შემდეგია:

• ტექნიკური დიზაინის განცხადება;
• ტექნიკური პროექტის ახსნა-განმარტება;
• ფუნქციური სტრუქტურის დიაგრამა;
• ტექნიკური საშუალებების კომპლექსის სტრუქტურული დიაგრამა;
• ორგანიზაციული სტრუქტურის დიაგრამა;
• შეძენილი ნივთების სია.

კლიენტის მოთხოვნით ან იმ შემთხვევაში, თუ ISS არის რთული მრავალკომპონენტიანი სისტემა, შემდეგი დოკუმენტები ასევე შეიძლება დამატებით შემუშავდეს:

• ავტომატიზაციის სქემა;
• ავტომატური ფუნქციების აღწერა;
• სისტემის საინფორმაციო მხარდაჭერის აღწერა;
• ტექნიკური საშუალებების კომპლექსის აღწერა;
• პროგრამული უზრუნველყოფის აღწერა;
• ორგანიზაციული სტრუქტურის აღწერა.

უნდა აღინიშნოს, რომ GOST 34.201-89 საშუალებას იძლევა გაზარდოს დოკუმენტების დიაპაზონი TP ეტაპზე, მაგრამ პრაქტიკაში ეს დოკუმენტები საკმარისზე მეტია.

ტექნიკური დიზაინის ფურცელი

აღნიშვნა: TP.

ეს დოკუმენტი გამიზნულია ტექნიკური პროექტის ეტაპზე შემუშავებული დოკუმენტების ჩამონათვალის აღსაწერად. ასევე მითითებულია თითოეული შემუშავებული დოკუმენტის გვერდების რაოდენობა.

ტექნიკური პროექტის ახსნა-განმარტება

აღნიშვნა: P2.

ეს დოკუმენტი არის მთავარი TP ეტაპისთვის და მოიცავს ISS არქიტექტურის, ტექნიკურ და ორგანიზაციულ ღონისძიებებს, ISS ფუნქციებს, პროგრამულ და აპარატურულ სისტემებს და სხვა საკითხებს. სტანდარტის მიხედვით, იგი შედგება ოთხი ძირითადი განყოფილებისგან:

• ზოგადი დებულებები;
• საქმიანობის პროცესის აღწერა;
• ძირითადი ტექნიკური გადაწყვეტილებები;
• ავტომატიზაციის ობიექტის მომზადების ღონისძიებები სისტემის ამოქმედებისთვის.

ფუნქციური სტრუქტურის დიაგრამა

აღნიშვნა: C2.

ეს დოკუმენტი აღწერს ISS-ის ლოგიკურ სტრუქტურას, კერძოდ:

• ISS-ში შემავალი ლოგიკური ქვესისტემები და კომპონენტები;
• ქვესისტემებისა და კომპონენტების საშუალებით განხორციელებული ფუნქციები;
• ინფორმაციის კავშირები SIS-ის ლოგიკურ ელემენტებსა და შეტყობინებების ტიპებს შორის გაცვლის დროს.

ტექნიკური საშუალებების კომპლექსის სტრუქტურული დიაგრამა

აღნიშვნა: C1.

ეს დოკუმენტი მოიცავს ISS-ის შემდეგი ელემენტების აღწერას:

• ტექნიკური საშუალებები, როგორც ინფორმაციული უსაფრთხოების სისტემების ლოგიკური ქვესისტემებისა და კომპონენტების ნაწილი;
• საკომუნიკაციო არხები და ტექნიკურ საშუალებებს შორის გაცვლა სატრანსპორტო პროტოკოლების მითითებით.

ორგანიზაციული სქემა

აღნიშვნა: C0.

ეს დოკუმენტი აღწერს ორგანიზაციის ორგანიზაციულ სტრუქტურას ISS მენეჯმენტის თვალსაზრისით, კერძოდ:

• ISS-ის ფუნქციონირებაში ჩართული ორგანიზაციის განყოფილებები და პასუხისმგებელი პირები;
• შესრულებული ფუნქციები და კავშირები დეპარტამენტებსა და პასუხისმგებელ პირებს შორის.

შეძენილი ნივთების სია

დანიშნულება: VP.

ეს დოკუმენტი მოიცავს ყველა პროგრამული უზრუნველყოფისა და აპარატურის ჩამონათვალს, ასევე ლიცენზიებს, რომლებიც გამოიყენება ინფორმაციული უსაფრთხოების სისტემის შესაქმნელად. შემუშავებულია GOST 2.106-ის შესაბამისად.

Შენიშვნა.აქვე უნდა აღინიშნოს, რომ სახელმძღვანელო დოკუმენტი RD 50-34.698-90 იძლევა ნებისმიერი დოკუმენტის დამატებას TP ეტაპზე (სექციების და ინფორმაციის ჩართვა შემოთავაზებულისგან განსხვავებული), სექციების შერწყმა და ასევე გამორიცხვა. ზოგიერთი ცალკეული განყოფილებიდან. ამის შესახებ გადაწყვეტილებებს იღებს დოკუმენტების შემქმნელი TP ეტაპზე და ეფუძნება შექმნილი NIB-ის მახასიათებლებს.

1.4. დოკუმენტაციის შემუშავების წესები

• სტრუქტურული შესაბამისობა სახელმწიფო სტანდარტებთან;
• სისტემის ტექნიკური მახასიათებლების მოთხოვნების მკაცრი დაცვა;
• დოკუმენტების შაბლონების გამოყენება (ერთგვაროვანი სტილის გამოყენება, მარკირება, ველები და ა.შ.);
• ინდივიდუალური მიდგომა და არსებული განვითარების ერთდროული გამოყენება დოკუმენტების სექციების შევსებისას.

ტექნიკური პროექტის ახსნა-განმარტება:

• დოკუმენტის შემუშავება ხორციელდება Microsoft Word-ში განვითარების დასრულების შემდეგ, მოხერხებულობისთვის რეკომენდებულია დოკუმენტის PDF ფორმატში გადაყვანა;
• ტერმინები და აბრევიატურები თანმიმდევრული უნდა იყოს დოკუმენტის ყველა ნაწილში;
• რეკომენდირებულია თავიდან იქნას აცილებული აშკარა გამეორება და დოკუმენტის სიგრძის არასაჭირო ზრდა;
• ტექნიკური გადაწყვეტილებები უნდა იყოს აღწერილი მაქსიმალურად დეტალურად, მითითებით:
  • გამოყენებული არქიტექტურა და ტექნოლოგიები;
  • პროგრამული უზრუნველყოფისა და ტექნიკის მდებარეობები ორგანიზაციის ინფრასტრუქტურაში;
  • ინფორმაციული უსაფრთხოების ინსტრუმენტები, რომლებიც გამოიყენება მათი მახასიათებლების აღწერით, განხორციელებული ფუნქციებით, ინფორმაცია სერტიფიცირების შესახებ;
  • ინფორმაციული უსაფრთხოების ინსტრუმენტების ძირითადი პარამეტრები დაცვის მექანიზმების, მისამართის, მარშრუტის, დაკავშირებულ სისტემებთან და ინსტრუმენტებთან ურთიერთქმედების თვალსაზრისით და ა.შ.
  • კონტროლი, მათზე წვდომის მეთოდები და მათი დაყენების ადგილები;
  • დიაგრამები (სტრუქტურული, ფუნქციონალური, ორგანიზაციული):
    • დიაგრამების შემუშავება Microsoft Visio-ში;
    • განვითარების შემდეგ, ჩადეთ დიაგრამები დოკუმენტში "Paste Special" დიალოგის გამოყენებით EMF ფორმატში (Windows მეტაფაილი);
    • სისტემის, ქვესისტემებისა და ქვესისტემების კომპონენტების ცალკეული დიაგრამების შემუშავება;
    • გააკეთეთ დიაგრამების დიზაინი ერთგვაროვანი, იგივე ელემენტების, აბრევიატურების, ხატების, ტექსტის სტილის და ა.შ.

1.5. რესურსები, რომლებიც დაგეხმარებათ დოკუმენტაციის შემუშავებაში

ინტერნეტი შეიცავს უზარმაზარ ინფორმაციას, რომელიც ამა თუ იმ ხარისხით შეიძლება დაეხმაროს ტექნიკური პროექტის დოკუმენტაციის შემუშავებაში. ძირითადი რესურსები წარმოდგენილია ქვემოთ მოცემულ ცხრილში.

მაგიდა. SIS ტექნიკური დიზაინის რესურსები

რესურსის ტიპი	ინფორმაცია	რესურსების მაგალითები
ფედერალური აღმასრულებელი ხელისუფლების ინტერნეტ პორტალები	მარეგულირებელი დოკუმენტები, მეთოდოლოგიური რეკომენდაციები, რეგისტრები (ინფორმაციული უსაფრთხოების სერტიფიცირებული სისტემების ჩათვლით), მონაცემთა ბაზები (დაუცველობისა და საფრთხეების მონაცემთა ბაზების ჩათვლით)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
ინფორმაციული უსაფრთხოების მწარმოებლების, ინფორმაციული უსაფრთხოების გადაწყვეტილებების დისტრიბუტორების ინტერნეტ პორტალები	ინფორმაციული უსაფრთხოების გადაწყვეტილებების აღწერა, ინფორმაციული უსაფრთხოების ოპერატიული დოკუმენტაცია, ანალიტიკური მასალები და სტატიები	Securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
სპეციალიზებული ინფორმაციული უსაფრთხოების რესურსები	ინფორმაციის უსაფრთხოების გადაწყვეტილებების შედარება, სტატიების მიმოხილვა ინფორმაციული უსაფრთხოების გადაწყვეტილებების შესახებ, ინფორმაციული უსაფრთხოების გადაწყვეტილებების ტესტები, სიღრმისეული ტექნიკური ინფორმაცია ინფორმაციული უსაფრთხოების ტექნოლოგიების შესახებ	anti-malware.ru bis-expert.ru safe.cnews.ru Securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org

1.6. ტექნიკური პროექტის ეტაპის დოკუმენტების მაგალითები

TP-ის ეტაპზე დოკუმენტაციის შინაარსის მოთხოვნების გასაგებად, ქვემოთ მოცემულია ძირითადი დოკუმენტების (დოკუმენტების სექციების) შევსების მაგალითები.

1.6.1. ტექნიკური პროექტის ახსნა-განმარტება

ახსნა-განმარტება საკმაოდ მოცულობითი დოკუმენტია, ამიტომ აქ მოცემულია განყოფილების „ძირითადი ტექნიკური გადაწყვეტილებების“ შინაარსის მაგალითი ერთ-ერთი SIS ქვესისტემის ნაწილში - უსაფრთხოების ანალიზის ქვესისტემა.

ISS უსაფრთხოების ანალიზის ქვესისტემა

ქვესისტემის სტრუქტურა და შემადგენლობა

უსაფრთხოების ანალიზის ქვესისტემა (SAS) შექმნილია პერსონალისა და ორგანიზაციის სერვერების ავტომატური სამუშაო სადგურების (AWS) უსაფრთხოების მდგომარეობის სისტემატური მონიტორინგისთვის. ESD-ის საფუძველია შპს Information Security-ის მიერ წარმოებული „ტესტი“ პროგრამული ინსტრუმენტი. SZI ტესტი სერთიფიცირებულია რუსეთის FSTEC-ის მიერ ინფორმაციის უსაფრთხოების ტექნიკური მახასიათებლების (TU) შესაბამისობისთვის და არადეკლარირებული შესაძლებლობების არარსებობის კონტროლის მე-4 დონისთვის.

ESD მოიცავს შემდეგ კომპონენტებს:

• ტესტი სერვერის მართვის სერვერი;
• სატესტო კონსოლის მართვის კონსოლი.

ქვესისტემის კომპონენტების აღწერა წარმოდგენილია ქვემოთ მოცემულ ცხრილში.

მაგიდა. ESD კომპონენტები

Კომპონენტი	აღწერა
ტესტი სერვერის მართვის სერვერი	უზრუნველყოფს სკანირების ამოცანების მართვას, ასრულებს სამუშაო სადგურისა და ორგანიზაციის სერვერების უსაფრთხოების მდგომარეობის მონიტორინგის ფუნქციებს. სკანირების პარამეტრები დაყენებულია საინფორმაციო უსაფრთხოების ადმინისტრატორის მიერ ტესტ სერვერის მართვის სერვერზე. ყველა შეგროვებული ინფორმაცია სკანირების შედეგების შესახებ ინახება ტესტის სერვერის სერვერის საცავში, რომელიც დაფუძნებულია Microsoft SQL Server 2008 მონაცემთა ბაზის მართვის სისტემაზე.
სატესტო კონსოლი	საშუალებას აძლევს ინფორმაციული უსაფრთხოების ადმინისტრატორს დაუკავშირდეს სატესტო სერვერს, ნახოს და შეცვალოს მისი კონფიგურაცია, შექმნას და შეცვალოს სკანირების ამოცანები, ნახოს ინფორმაცია ამოცანების პროგრესისა და მათი შესრულების შედეგების შესახებ. მართვის კონსოლი დამონტაჟებულია ინფორმაციული უსაფრთხოების ადმინისტრატორის სამუშაო სადგურზე

ფუნქციების უზრუნველყოფა

ESD უზრუნველყოფს შემდეგ ფუნქციებს:

• ორგანიზაციის სამუშაო სადგურებისა და სერვერების პროაქტიული დაცვის განხორციელება ინფორმაციული უსაფრთხოების მდგომარეობის მონიტორინგით;
• შიდა პოლიტიკასთან და უსაფრთხოების გარკვეულ სტანდარტებთან შესაბამისობის მონიტორინგის პროცესების ავტომატიზაცია;
• აუდიტისა და უსაფრთხოების კონტროლის ხარჯების შემცირება, სტატუსის ანგარიშების მომზადება;
• რესურსების ინვენტარიზაციის პროცესების ავტომატიზაცია, დაუცველობის მართვა, უსაფრთხოების პოლიტიკასთან შესაბამისობის მონიტორინგი და ცვლილებების კონტროლი.

გადაწყვეტა აპარატურული და პროგრამული ინსტრუმენტების კომპლექსისთვის

გამოყენებული ESD პროგრამული უზრუნველყოფის და აპარატურის სია მოცემულია ქვემოთ მოცემულ ცხრილში.

მაგიდა. ESD პროგრამული უზრუნველყოფა და აპარატურა

ESD კონტროლის სერვერი

ტექნიკური საშუალებები

ESD მენეჯმენტის სერვერად გამოყენებული ფიზიკური სერვერი უნდა აკმაყოფილებდეს ტექნიკურ მოთხოვნებს მასზე დაინსტალირებული პროგრამული უზრუნველყოფისა და ოპერაციული სისტემისთვის, რომელიც მოცემულია ქვემოთ მოცემულ ცხრილში.

მაგიდა. OS და პროგრამული მოთხოვნები ESD კონტროლის სერვერისთვის

პროგრამული უზრუნველყოფა	Ტექნიკური მოთხოვნები
	პროცესორი	ოპერატიული მეხსიერება, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 ბირთვი	8192
Microsoft SQL Server 2008 R2
ტესტი სერვერის პროგრამული უზრუნველყოფა

პროგრამული უზრუნველყოფა

მართვის სერვერის OS

Windows 2008 R2 OS დაინსტალირებულია მართვის სერვერზე ნორმალური წესით ჩატვირთვის განაწილებიდან.

მენეჯმენტის სერვერის OS იმართება როგორც ლოკალურად კონსოლიდან, ასევე RDP პროტოკოლის მეშვეობით.

მართვის სერვერი DBMS

Microsoft SQL Server 2008 R2 მონაცემთა ბაზა დაინსტალირებულია ანგარიშის ქვეშ, ადგილობრივი ადმინისტრატორის უფლებებით, სტანდარტული ინსტალაციის ოსტატის გამოყენებით, პროდუქტის შემქმნელის მიერ მოწოდებული სადისტრიბუციო ნაკრებიდან.

ტესტი სერვერის პროგრამული უზრუნველყოფა

სატესტო სერვერის პროგრამული უზრუნველყოფა დაინსტალირებულია მართვის სერვერზე სტანდარტული ინსტალაციის ოსტატის გამოყენებით.

ტესტი სერვერის პროგრამული უზრუნველყოფის საწყისი დაყენება და შემდგომი მართვა ნორმალურ რეჟიმში ხორციელდება IS ადმინისტრატორის სამუშაო სადგურზე დაინსტალირებული Test Console მართვის კონსოლის გამოყენებით.

IS ადმინისტრატორის სამუშაო სადგური

ტექნიკური საშუალებები

პლატფორმად გამოიყენება ორგანიზაციული ერთეულის თანამშრომლის არსებული სამუშაო ადგილი, რომელიც პასუხისმგებელია ინფორმაციული უსაფრთხოების უზრუნველყოფაზე, რომელიც მუშაობს Microsoft Windows-ის ოპერაციული სისტემების ოჯახში.

ინფორმაციული უსაფრთხოების ადმინისტრატორის სამუშაო სადგურის ტექნიკურ საშუალებებს უნდა ჰქონდეს შემდეგი ტექნიკის კონფიგურაციის მახასიათებლები (მინიმუმ რეკომენდირებულია):

• CPU 2 GHz;
• ოპერატიული მეხსიერება 4 გბ;
• HDD 80 GB.

პროგრამული უზრუნველყოფა

სატესტო კონსოლის პროგრამული უზრუნველყოფა

ინფორმაციული უსაფრთხოების ადმინისტრატორის სამუშაო სადგური, რომელზედაც დაინსტალირებულია სატესტო კონსოლის პროგრამული უზრუნველყოფა, უნდა მუშაობდეს ერთ-ერთი შემდეგი OS-ით:

• Microsoft Windows 7, 32- და 64-bit;
• Microsoft Windows 8/8.1, 32- და 64-ბიტიანი.

გარდა ამისა, იმისათვის, რომ სატესტო კონსოლის მართვის კონსოლის პროგრამული უზრუნველყოფა სწორად იმუშაოს, Microsoft .NET Framework ვერსია 3.5 SP1 ან უფრო მაღალი უნდა იყოს დაინსტალირებული ინფორმაციული უსაფრთხოების ადმინისტრატორის სამუშაო სადგურზე და გამოყენებული ოპერაციული სისტემის უსაფრთხოების პარამეტრები უნდა დაუშვას ტესტის სერვერზე წვდომას.

სატესტო კონსოლის პროგრამული უზრუნველყოფის ინსტალაცია ESD ადმინისტრატორის სამუშაო სადგურზე ხორციელდება სტანდარტული Test Server პროგრამული უზრუნველყოფის ინსტალაციის ოსტატის გამოყენებით, არჩეული ვარიანტით Test Console მართვის კონსოლის და სხვა ნაგულისხმევი პარამეტრების დასაყენებლად.

ურთიერთქმედება მიმდებარე სისტემებთან

ESD-სთვის, მიმდებარეა:

• firewall ქვესისტემის ხელსაწყოები;
• Active Directory დირექტორია სერვისები;
• სამუშაო სადგური და ორგანიზაციის სერვერები.

ქსელის ურთიერთქმედების უზრუნველსაყოფად მიმდებარე სისტემებთან და უშუალოდ თავად ESD კომპონენტებს შორის, უნდა იყოს ორგანიზებული საჭირო ქსელის ტრაფიკის გავლა.

ტესტის სერვერის სკანერისთვის ცოდნის ბაზის განახლებების და სატესტო პროგრამული მოდულების მიღების შესაძლებლობის უზრუნველსაყოფად, აუცილებელია შპს Information Security LLC-ის update.com ვებ სერვერზე წვდომის უზრუნველყოფა პორტით 443/tcp.

PenTest რეჟიმში სკანირებისას, ტესტი სერვერის სკანერსა და სამუშაო სადგურსა და ორგანიზაციის სერვერებს შორის ურთიერთქმედება ხორციელდება IP პროტოკოლის მეშვეობით. აუდიტის და შესაბამისობის რეჟიმებში სკანირებისას გამოიყენება დისტანციური მართვის პროტოკოლები WMI, RPC და ა.შ. ჰოსტების სკანირებისთვის მოწყობილობებზე firewall-ის ფუნქციებით, თქვენ უნდა დაუშვათ კავშირები ტესტის სერვერიდან დასკანირებულ ჰოსტებთან. შესაბამისად, სატესტო სერვერს უნდა ჰქონდეს წვდომა სკანირებული ჰოსტების ქსელის პორტებზე შესაბამისი დისტანციური მართვის პროტოკოლების გამოყენებით.

ვინაიდან ESD, აუდიტისა და შესაბამისობის რეჟიმებში სკანირებისას, ანალიზისთვის იყენებს დისტანციური მართვის პროტოკოლებს, ტესტის პროგრამული სკანირების ხელსაწყოებმა უნდა გაიარონ ავტორიზაცია და ავტორიზაცია დასკანირებულ კვანძზე. ESD-ში, აუდიტის და შესაბამისობის რეჟიმებში კვანძების სკანირებისთვის, ადმინისტრაციული პრივილეგიებით ანგარიშები გამოიყენება კვანძის თითოეულ ტიპში (სამუშაო სადგური, სერვერი, აპლიკაციის სისტემები, DBMS და ა.შ.).

ინფორმაციული უსაფრთხოების ყველა რეგისტრირებული მოვლენა ინახება Microsoft SQL DBMS-ში. ეს მოვლენები შეიძლება გაიგზავნოს ინფორმაციული უსაფრთხოების ღონისძიებების მონიტორინგის ქვესისტემაში სპეციალური კონექტორების გამოყენებით.

ESD-ის ექსპლუატაცია და შენარჩუნება

ქვესისტემის მომხმარებლები

ESD ინსტრუმენტების ექსპლუატაცია და მოვლა ხორციელდება ორგანიზაციის თანამშრომლების მიერ „IS ადმინისტრატორის“ ფუნქციური როლით.

ინფორმაციული უსაფრთხოების ადმინისტრატორი განისაზღვრება, როგორც სპეციალისტი, რომლის ამოცანები მოიცავს:

• ორგანიზაციის კვანძების სკანირების პარამეტრების განსაზღვრა;
• სკანირების ამოცანების დაყენება და გაშვება;
• სკანირების შედეგების ანალიზი საინფორმაციო სისტემებში დაუცველობის არსებობის, კონფიგურაციის შეცდომების ან ტექნიკურ სტანდარტებთან შეუსაბამობაზე;
• მოწყვლადობის აღმოფხვრაზე კონტროლი;
• სტანდარტებისა და მოთხოვნების ფორმირება, რომლებიც ეხება ორგანიზაციის სამუშაო სადგურებისა და სერვერების უსაფრთხოების უზრუნველყოფას.

სისტემის მუშაობის რეჟიმები

ნორმალური მუშაობის რეჟიმი

ნორმალურ რეჟიმში, ESD მუშაობს 24 საათის განმავლობაში, კვირაში 7 დღე.

ნორმალურ მუშაობაში, ინფორმაციის უსაფრთხოების ადმინისტრატორი ასრულებს:

• კვანძების დაგეგმილი და არაგეგმიური სკანირება;
• ანგარიშების გენერირება;
• ცოდნის ბაზებისა და სატესტო პროგრამული მოდულების განახლება.

გადაუდებელი ოპერაცია

უსაფრთხოების აღჭურვილობის მუშაობის შეფერხების შემთხვევაში, ქვესისტემის ფუნქციონირება ირღვევა. ESD აღჭურვილობის წარუმატებლობა გავლენას არ ახდენს ორგანიზაციის ავტომატური სამუშაო სადგურებისა და სერვერების ფუნქციონირებაზე.

1.6.2. ფუნქციური სტრუქტურის დიაგრამა

ფუნქციური დიაგრამები შეიძლება შემუშავდეს ინფორმაციული უსაფრთხოების მთელი სისტემისთვის ან მისი ნაწილისთვის, მაგალითად, ქვესისტემისთვის ან კომპონენტისთვის.

ISS-ის ზოგადი ფუნქციონალური სქემის მაგალითი ნაჩვენებია ქვემოთ მოცემულ ფიგურაში.

1.6.3. ტექნიკური საშუალებების კომპლექსის სტრუქტურული დიაგრამა

ტექნიკური საშუალებების კომპლექსის ბლოკ-სქემა შეიძლება შემუშავდეს როგორც მთელი ISS-ისთვის, ასევე მისი ნაწილებისთვის - ქვესისტემებისა და კომპონენტებისთვის. ინფორმაციული უსაფრთხოების სისტემის ნაწილებისთვის დიაგრამების შემუშავების მიზანშეწონილობა განისაზღვრება სისტემის მასშტაბით და საჭირო დეტალით.

ტექნიკური ინფორმაციისა და უსაფრთხოების სისტემების კომპლექსის ბლოკ-სქემის მაგალითი წარმოდგენილია ქვემოთ მოცემულ ფიგურაში.

რუსეთის ფედერაციის ეკონომიკური განვითარებისა და ვაჭრობის სამინისტრო

მე დავამტკიცე

რუსეთის ფედერაციის ეკონომიკური განვითარებისა და ვაჭრობის სამინისტროსა და CJSC PROGNOZ-ს შორის დადებული 2007 წლის 29 ოქტომბრის №000-05-07 სახელმწიფო ხელშეკრულება თემაზე „სოციალური მონიტორინგის ფედერალური მონიტორინგის ავტომატური მოდულის შემუშავება“. რუსეთის ფედერაციის შემადგენელი ერთეულების ეკონომიკური განვითარება რუსეთის ფედერაციის სოციალურ-ეკონომიკური განვითარების ძირითადი ინდიკატორების მონიტორინგის ერთიანი საინფორმაციო სისტემის შექმნისა და მათ მიღწევაში სამთავრობო ორგანოების საქმიანობის მონიტორინგის ფარგლებში. ამ დოკუმენტის შემუშავებისას გამოყენებული იქნა სახელმძღვანელო დოკუმენტი სტანდარტიზაციის შესახებ GOST RD 50-34.698-90. 1. ზოგადი დებულებები... 5 1.1. სისტემის სრული დასახელება... 5 1.2. დოკუმენტები, რომელთა საფუძველზეც ხორციელდება პროექტი.. 5 1.3. ეტაპები და ვადები.. 5 1.4. მიზნები და მიზანი.. 7 1.5. საპროექტო გადაწყვეტილებების შესაბამისობა უსაფრთხოების მოთხოვნებთან.. 8 1.6. მარეგულირებელი და ტექნიკური დოკუმენტები... 9 2. საქმიანობის პროცესის აღწერა.. 10 2.1. ამოცანების სია... 10 2.2. მოდულის მიერ შესრულებული ძირითადი ფუნქციები... 11 3. ძირითადი ტექნიკური გადაწყვეტილებები.. 13 3.1. მოდულის სტრუქტურა, ქვესისტემების სია... 13 3.1.1. მონაცემთა ცენტრალიზებული შენახვის ქვესისტემა. 14 3.1.2. ინტერფეისის კომპონენტი. 15 3.1.3. ადაპტერის პროგრამული კომპონენტები. 16 3.6.3. ავტომატიზაციის ობიექტის პარამეტრებში გადახრებთან ადაპტაციის ხარისხი. 26 3.6.4. სისტემის მოდერნიზაციისა და განვითარების მისაღები ლიმიტები.. 26 3.6.5. სანდოობის მოთხოვნები. 27 3.6.6. უსაფრთხოების მოთხოვნა. 27 3.6.7. ერგონომიკისა და ტექნიკური ესთეტიკის მოთხოვნები. 28 ნამუშევრების სია სამუშაოს მოსალოდნელი შედეგები სოციალურ-ეკონომიკური ინფორმაციის ცენტრალიზებული მონაცემთა საცავის (CDW) შემუშავება, რომელიც გამოიყენება რუსეთის ფედერაციის შემადგენელი ერთეულებისა და მუნიციპალიტეტების სოციალურ-ეკონომიკური განვითარების ინდიკატორების (PSED) ფედერალური მონიტორინგის განხორციელებისას. მონაცემთა შენახვის ცენტრალიზებული ქვესისტემა PSED მონაცემთა სქემებისა და ტექნოლოგიური სპეციფიკაციების პროფილების შემუშავება, რომლებიც აღწერს პროტოკოლებს ინტერფეისის კომპონენტთან და გამოქვეყნებული PSED მონაცემების ფორმატებთან ურთიერთქმედებისთვის PSER მონაცემთა სქემები და ტექნოლოგიური სპეციფიკაციების პროფილები, რომლებიც აღწერს ინტერფეისის კომპონენტთან ურთიერთქმედების პროტოკოლებს და გამოქვეყნებული PSER მონაცემების ფორმატებს; მოხსენება მონაცემთა სქემებისა და ტექნოლოგიური სპეციფიკაციების პროფილების სპეციფიკაციების პროექტის განხილვის შესახებ, დისკუსიის მონაწილეთა ჩაწერილი კომენტარებითა და წინადადებებით. ინტერფეისის კომპონენტისთვის კროს-პლატფორმული პროგრამული უზრუნველყოფის შემუშავება, ტესტირება საპილოტე განხორციელების ადგილებში და გამოვლენილი კომენტარების შესაბამისად დახვეწა ინტერფეისის კომპონენტები ადაპტერის სავალდებულო კომპონენტი სპეციფიკური ადაპტერის კომპონენტების შემუშავება, რომელიც უზრუნველყოფს EMS-ის შესახებ ინფორმაციის ავტომატიზირებულ მოძიებას AIS-ის ძველი წყაროებიდან და მის გამოქვეყნებას ინტერფეისის კომპონენტის მეშვეობით მისი სპეციფიკაციების შესაბამისად. სპეციფიკური გადამყვანები უნდა შეიცავდეს გადამოწმების ერთეულს და შეამოწმონ სტატისტიკური ინფორმაციის სანდოობა ადაპტერის სპეციფიკური კომპონენტები; ფედერალური მონიტორინგის განხორციელებისას გამოყენებული ინფორმაციის ავტომატური შეგროვების წესები და მოწოდებული ვებსაიტებიდან და ფედერალური სამინისტროებისა და დეპარტამენტების, რუსეთის ფედერაციის შემადგენელი ერთეულების, მუნიციპალიტეტების AIS-დან, გამომავალი პარამეტრების შემუშავებული სპეციფიკაციების შესაბამისად, რომლებიც განკუთვნილია ინფორმაციის მიწოდებისთვის. ამ მონაცემთა წყაროები რუსეთის ფედერაციის შემადგენელი ერთეულების სოციალურ-ეკონომიკური განვითარების მონიტორინგისა და ანალიზის შედეგების ტაბულური, გრაფიკული, კარტოგრაფიული, ტექსტური წარმოდგენის ინსტრუმენტების შემუშავება. რუსეთის ფედერაციის შემადგენელი სუბიექტების მონიტორინგის მონაცემებისა და სოციალურ-ეკონომიკური განვითარების ანალიზის შედეგების ტაბულური, გრაფიკული, კარტოგრაფიული, ტექსტური წარმოდგენის ქვესისტემა მოდულის ქვესისტემის შემუშავება, რომელიც შექმნილია ფედერალური მონიტორინგის პროცესში შეგროვებული ინფორმაციის საფუძველზე ფედერაციის შემადგენელი ერთეულების ეკონომიკური სექტორების განვითარების შეფასების კრიტერიუმების გამოსათვლელად. რუსეთის ფედერაციის შემადგენელი ერთეულების ეკონომიკური სექტორების განვითარების შეფასების კრიტერიუმების გამოთვლის ქვესისტემა (რეგიონული კლასტერების იდენტიფიცირების შესაძლებლობით) ფედერალური მონიტორინგის პროცესში შეგროვებული ინფორმაციის საფუძველზე. მოდულის ქვესისტემის შემუშავება, რომელიც შექმნილია ფედერალური სუბიექტების ინტეგრალური ინდექსების და სოციალურ-ეკონომიკური განვითარების შეფასების გამოსათვლელად, ფედერალური მონიტორინგის პროცესში შეგროვებული ინფორმაციის საფუძველზე. ფედერალური მონიტორინგის პროცესში შეგროვებული ინფორმაციის საფუძველზე რუსეთის ფედერაციის შემადგენელი ერთეულების სოციალურ-ეკონომიკური განვითარების ინტეგრალური ინდექსების და შეფასების ქვესისტემა მოდულის ქვესისტემის შემუშავება, რომელიც განკუთვნილია ელექტრონული ენერგეტიკული სისტემის შესახებ ინფორმაციის გამოსაქვეყნებლად მოქმედი რეგულაციების მოთხოვნების შესაბამისად და შემუშავებული პროექტის ფარგლებში, აგრეთვე ინტერფეისის კომპონენტის სპეციფიკაციების შესაბამისად. მოდულში შენახული ელექტრონული ენერგეტიკული სისტემის შესახებ პირველადი და კონვერტირებული ინფორმაციის საჯაროდ ხელმისაწვდომი გამოქვეყნების ქვესისტემა ადმინისტრაციის ქვესისტემის განვითარება ადმინისტრაციის ქვესისტემა ფედერალური მონიტორინგის მოდულის დიზაინის დოკუმენტაციის სრული პაკეტი GOST 34-ის მოთხოვნების შესაბამისად მიღების ტესტების ჩატარება, მოდულის დასრულება მომხმარებლის კომენტარების შესაბამისად

1. ზოგადი დებულებები;
2. საქმიანობის აღწერა;
3. ძირითადი ტექნიკური გადაწყვეტილებები;
4. მოვლენების შესახებ

[პუნქტიდან 2.2.1 RD 50-34.698-90]

ზოგადი დებულებები

"ზოგადი დებულებების" განყოფილებაში ისინი უზრუნველყოფენ:

1. დოკუმენტების დიზაინი და სახელები, მათი ნომრები და თარიღი, რომლის საფუძველზეც ხორციელდება ატომური ელექტროსადგურის პროექტი;
2. სისტემაში ჩართულთა სია, ვადები;
3. მიზნები, მიზანი და AS;
4. საპროექტო გადაწყვეტილებების შესაბამისობის დადასტურება მოქმედ სტანდარტებთან და ხანძარსაწინააღმდეგო და აფეთქების უსაფრთხოებასთან და ა.შ.
5. ინფორმაცია დიზაინში გამოყენებული პირების შესახებ;
6. ინფორმაცია პროექტის შემუშავებისას გამოყენებული საუკეთესო პრაქტიკის შესახებ;
7. სისტემის შექმნის რიგი და თითოეულის მოცულობა.

[პუნქტიდან 2.2.2 RD 50-34.698-90]

აქტივობის პროცესის აღწერა

განყოფილებაში "აქტივობის პროცესის აღწერა" ისინი ასახავს პროცედურების შემადგენლობას (), პროცესებისა და აქტივობების ურთიერთკავშირისა და თავსებადობის გათვალისწინებით, ქმნიან ქარხანაში მუშაობის ორგანიზაციას [პუნქტიდან 2.2.3 RD 50-34.698. -90]

ძირითადი ტექნიკური გადაწყვეტილებები

განყოფილებაში "მთავარი ტექნიკური გადაწყვეტილებები" მოცემულია:

1. გადაწყვეტილებები ქვესისტემებს შორის ინფორმაციის გაცვლის სისტემის სტრუქტურის, საშუალებებისა და კომუნიკაციის მეთოდების შესახებ;
2. გადაწყვეტილებები სისტემის ურთიერთდაკავშირების შესახებ დაკავშირებულ სისტემებთან და მის მხარდაჭერაზე;
3. გადაწყვეტილებები სისტემის მუშაობისთვის;
4. გადაწყვეტილებები რაოდენობის, კვალიფიკაციისა და ფუნქციების, მისი მოქმედების რეჟიმების, ურთიერთქმედების რიგის შესახებ;
5. ინფორმაცია სისტემის (ქვესისტემების) განსაზღვრული სამომხმარებლო მახასიათებლების უზრუნველსაყოფად, რომელიც განსაზღვრავს მას;
6. სისტემის (ქვესისტემის) მიერ განხორციელებული ამოცანების კომპლექსების () შემადგენლობა;
7. გადაწყვეტილებები კომპლექსის შესახებ, მისი განთავსება;
8. გადაწყვეტილებები ინფორმაციის შემადგენლობის, მოცულობის, მეთოდების, კომპიუტერის ტიპებისა და დოკუმენტების, თანმიმდევრობისა და სხვა კომპონენტების შესახებ;
9. გადაწყვეტილებები შემადგენლობის, საქმიანობის ენების, პროცედურებისა და ოპერაციების და მათი განხორციელების მეთოდების შესახებ.

განყოფილებაში მოცემულია სხვა დოკუმენტების ილუსტრაციები, რომლებიც შეიძლება ჩართული იყოს GOST 34.201-ის შესაბამისად [RD 50-34.698-90-ის 2.2.4 პუნქტიდან]

ავტომატიზაციის ობიექტის მომზადების ღონისძიებები სისტემის ამოქმედებისთვის

განყოფილებაში „სისტემის ამოქმედების მოსამზადებელი ღონისძიებები“ მოცემულია შემდეგი:

1. ზომები ინფორმაციის შესაფერის ფორმაში მოსაყვანად;
2. პერსონალის კვალიფიკაციის მომზადებისა და ტესტირების ღონისძიებები;
3. ღონისძიებები საჭირო ერთეულებისა და სამუშაო ადგილების შესაქმნელად;
4. ზომები ავტომატიზაციის ობიექტის შეცვლისთვის;
5. სხვა ზომები, რომლებიც ეფუძნება შექმნილი სისტემების სპეციფიკურ მახასიათებლებს.