და პროგრამული დოკუმენტაცია.
ESPD სტანდარტები ადგენს მოთხოვნებს, რომლებიც არეგულირებს პროგრამების შემუშავებას, შენარჩუნებას, წარმოებას და ექსპლუატაციას, რაც უზრუნველყოფს:
- პროგრამული პროდუქტების გაერთიანება პროგრამების ურთიერთგაცვლისთვის და ადრე შემუშავებული პროგრამების ახალ განვითარებაში გამოყენება;
- შრომის ინტენსივობის შემცირება და პროგრამული პროდუქტების განვითარების, მოვლის, წარმოებისა და ექსპლუატაციის ეფექტურობის გაზრდა;
- პროგრამული დოკუმენტაციის წარმოებისა და შენახვის ავტომატიზაცია.
პროგრამის შენარჩუნება მოიცავს პროგრამის ფუნქციონირების, განვითარებისა და გაუმჯობესების ანალიზს, ასევე მასში ცვლილებების შეტანას შეცდომების აღმოსაფხვრელად.
ESPD-ში შეტანილი სტანდარტების სია
- GOST 19.001-77. ESPD. ზოგადი დებულებები.
- GOST 19.003-80. ESPD. ალგორითმებისა და პროგრამების სქემები. სიმბოლოები ჩვეულებრივი გრაფიკაა.
- GOST 19.005-85. ESPD. ალგორითმებისა და პროგრამების P-სქემები. ჩვეულებრივი გრაფიკული აღნიშვნები და შესრულების წესები.
- GOST 19.101-77. ESPD. პროგრამების სახეები და პროგრამული დოკუმენტები.
- GOST 19.102-77. ESPD. განვითარების ეტაპები.
- GOST 19.103-77. ESPD. პროგრამებისა და პროგრამული დოკუმენტების აღნიშვნა.
- GOST 19.104-78. ESPD. ძირითადი წარწერები.
- GOST 19.105-78. ESPD. ზოგადი მოთხოვნები პროგრამის დოკუმენტებისთვის.
- GOST 19.106-78. ESPD. მოთხოვნები დაბეჭდილი პროგრამის დოკუმენტებისთვის.
- GOST 19.201-78. ESPD. ტექნიკური დავალება. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.202-78. ESPD. სპეციფიკაცია. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.301-79. ESPD. ტესტის პროგრამა და მეთოდოლოგია. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.401-78. ESPD. პროგრამის ტექსტი. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.402-78. ESPD. პროგრამის აღწერა.
- GOST 19.403-79. ESPD. ორიგინალური მფლობელების სია.
- GOST 19.404-79. ESPD. განმარტებითი შენიშვნა. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.501-78. ESPD. ფორმა. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.502-78. ESPD. განაცხადის აღწერა. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.503-79. ESPD. სისტემის პროგრამისტის სახელმძღვანელო. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.504-79. ESPD. პროგრამისტის სახელმძღვანელო. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.505-79. ESPD. ოპერატორის სახელმძღვანელო. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.506-79. ESPD. ენის აღწერა. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.507-79. ESPD. საოპერაციო დოკუმენტების სია.
- GOST 19.508-79. ESPD. ტექნიკური სახელმძღვანელო. მოთხოვნები შინაარსისა და დიზაინისთვის.
- GOST 19.601-78. ESPD. დუბლირების, აღრიცხვისა და შენახვის ზოგადი წესები.
- GOST 19.602-78. ESPD. დაბეჭდილი პროგრამული დოკუმენტების დუბლირების, აღრიცხვისა და შენახვის წესები.
- GOST 19.603-78. ESPD. ცვლილებების შეტანის ზოგადი წესები.
- GOST 19.604-78. ESPD. დაბეჭდილი პროგრამის დოკუმენტებში ცვლილებების შეტანის წესები.
- GOST 19.701-90 (ISO 5807-85). ESPD. ალგორითმების, პროგრამების, მონაცემებისა და სისტემების სქემები. კონვენციები და აღსრულების წესები.
იხილეთ ასევე
ბმულები
ფონდი ვიკიმედია. 2010 წელი.
ნახეთ, რა არის „პროგრამული უზრუნველყოფის დოკუმენტაციის ერთიანი სისტემა“ სხვა ლექსიკონებში:
- (ESKD) სახელმწიფო სტანდარტების ერთობლიობა, რომელიც ადგენს ურთიერთდაკავშირებულ წესებს, მოთხოვნებსა და ნორმებს საპროექტო დოკუმენტაციის შემუშავების, შესრულებისა და მიმოქცევისთვის, შემუშავებული და გამოყენებული ცხოვრების ციკლის ყველა ეტაპზე... ვიკიპედია
სისტემა- 4.48 სისტემა: ურთიერთქმედების ელემენტების ერთობლიობა, რომელიც ორგანიზებულია ერთი ან მეტი განსაზღვრული მიზნის მისაღწევად. შენიშვნა 1 სისტემა შეიძლება ჩაითვალოს პროდუქტად ან მის მიერ მოწოდებულ მომსახურებად. შენიშვნა 2 პრაქტიკაში......
RD 153-34.1-35.521-00: სახელმძღვანელო მითითებები. თბოელექტროსადგურების ავტომატური პროცესის კონტროლის სისტემების (TAI) საამქროებში ოპერატიული დოკუმენტაციის შედგენა და მოვლა.- Terminology RD 153 34.1 35.521 00: Guidelines. თბოელექტროსადგურების ავტომატური პროცესის მართვის სისტემების (TAI) საამქროებში საოპერაციო დოკუმენტაციის შედგენა და მოვლა: 1. პროცესის მართვის ავტომატური სისტემა (APCS) სისტემა... ... ნორმატიული და ტექნიკური დოკუმენტაციის ტერმინთა ლექსიკონი-საცნობარო წიგნი
- (EIS) არის ორგანიზაციული, ტექნიკური, პროგრამული და საინფორმაციო ხელსაწყოების ერთობლიობა, რომელიც გაერთიანებულია ერთ სისტემაში, რათა შეაგროვოს, შეინახოს, დაამუშავოს და გასცეს საჭირო ინფორმაცია, რომელიც განკუთვნილია ფუნქციების შესასრულებლად... ... ვიკიპედია
ESPD- პროგრამული დოკუმენტაციის ერთიანი სისტემა... რუსული აბრევიატურების ლექსიკონი
პროგრამული დოკუმენტაციის ერთიანი სისტემა (USPD) არის სახელმწიფო სტანდარტების ერთობლიობა, რომელიც ადგენს ურთიერთდაკავშირებულ წესებს პროგრამებისა და პროგრამული დოკუმენტაციის შემუშავების, შესრულებისა და მიმოქცევისთვის. ESPD სტანდარტები ადგენს მოთხოვნებს... ... ვიკიპედია
- (TOR, მითითების პირობები) პროდუქტის შემუშავებისა და ტესტირების წყარო დოკუმენტი. სარჩევი 1 TK-ის კონცეფცია 2 TK-ის ადგილი სტრუქტურებში ... ვიკიპედია
ოპერატიული დოკუმენტაცია- 30 საოპერაციო დოკუმენტაცია ფორმულირების დოკუმენტაცია, დამზადებულია GOST 2.601 95 მოთხოვნების შესაბამისად (პასპორტი, საოპერაციო ინსტრუქციები და ა.შ.)
GOST 19.101-77
ჯგუფი T55
სახელმწიფოთაშორისი სტანდარტი
პროგრამული დოკუმენტაციის ერთიანი სისტემა
პროგრამების სახეები და პროგრამული დოკუმენტები
პროგრამის დოკუმენტაციის ერთიანი სისტემა. პროგრამების სახეები და პროგრამული დოკუმენტები
35.080 MKS
შესავლის თარიღი 1980-01-01
სსრკ მინისტრთა საბჭოს სტანდარტების სახელმწიფო კომიტეტის 1977 წლის 20 მაისის N 1268 დადგენილებით, შემოღების თარიღი განისაზღვრა 01/01/80 წ.
გამოცემა (2010 წლის იანვარი) შესწორებით No1, დამტკიცებული 1981 წლის ივნისში (IUS 9-81).
ეს სტანდარტი ადგენს პროგრამებისა და პროგრამული დოკუმენტების ტიპებს კომპიუტერებისთვის, კომპლექსებისთვის და სისტემებისთვის, მიუხედავად მათი მიზნისა და მოცულობის.
სტანდარტი სრულად შეესაბამება ST SEV 1626-79-ს.
(შეცვლილი გამოცემა, შესწორება No1).
1. პროგრამების სახეები
1. პროგრამების სახეები
1.1. პროგრამა (GOST 19781-90-ის მიხედვით) შეიძლება იყოს იდენტიფიცირებული და გამოყენებული დამოუკიდებლად და (ან) როგორც სხვა პროგრამების ნაწილი.
1.2. პროგრამები იყოფა 1-ელ ცხრილში ნაჩვენები ტიპებად.
ცხრილი 1
პროგრამის ტიპი | განმარტება |
Კომპონენტი | პროგრამა, რომელიც განიხილება მთლიანობაში, ასრულებს სრულ ფუნქციას და გამოიყენება დამოუკიდებლად ან კომპლექსის ნაწილად |
კომპლექსი | პროგრამა, რომელიც შედგება ორი ან მეტი კომპონენტისგან და (ან) კომპლექსისგან, რომლებიც ასრულებენ ურთიერთდაკავშირებულ ფუნქციებს და გამოიყენება დამოუკიდებლად ან სხვა კომპლექსის ნაწილად. |
1.3. პროგრამისთვის შემუშავებული დოკუმენტაცია შეიძლება გამოყენებულ იქნას პროგრამის განსახორციელებლად და გადასატანად შესანახ მედიაზე, ასევე პროგრამული პროდუქტის დასამზადებლად.
1.2, 1.3. (შეცვლილი გამოცემა, შესწორება No1).
2. პროგრამული დოკუმენტების სახეები
2.1. პროგრამული დოკუმენტები მოიცავს დოკუმენტებს, რომლებიც შეიცავს ინფორმაციას პროგრამების შემუშავების, წარმოების, შენარჩუნებისა და მუშაობისთვის.
2.2. პროგრამული დოკუმენტების ტიპები და მათი შინაარსი მოცემულია ცხრილში 2.
მაგიდა 2
პროგრამის დოკუმენტის ტიპი | |
სპეციფიკაცია | პროგრამის შემადგენლობა და მისი დოკუმენტაცია |
საწარმოების სია, რომლებიც ინახავენ ორიგინალური პროგრამის დოკუმენტებს |
|
პროგრამის ტექსტი | პროგრამის ჩაწერა საჭირო კომენტარებით |
პროგრამის აღწერა | ინფორმაცია პროგრამის ლოგიკური სტრუქტურისა და მუშაობის შესახებ |
პროგრამის ტესტირებისას შესამოწმებელი მოთხოვნები, ასევე მათი კონტროლის პროცედურა და მეთოდები |
|
ტექნიკური დავალება | პროგრამის მიზანი და მოცულობა, ტექნიკური, მიზანშეწონილობა და სპეციალური მოთხოვნები პროგრამისთვის, შემუშავების აუცილებელი ეტაპები და ვადები, ტესტების სახეები. |
განმარტებითი შენიშვნა | ალგორითმის დიაგრამა, პროგრამის ალგორითმის და (ან) მუშაობის ზოგადი აღწერა, აგრეთვე მიღებული ტექნიკური და ტექნიკურ-ეკონომიკური გადაწყვეტილებების დასაბუთება. |
ოპერატიული დოკუმენტები | ინფორმაცია პროგრამის ფუნქციონირებისა და ფუნქციონირების უზრუნველსაყოფად |
2.3. ოპერატიული დოკუმენტების სახეები და მათი შინაარსი მოცემულია ცხრილში 3.
ცხრილი 3
ოპერატიული დოკუმენტის ტიპი | |
პროგრამის საოპერაციო დოკუმენტების სია |
|
ფორმა | პროგრამის ძირითადი მახასიათებლები, სისრულე და ინფორმაცია პროგრამის მუშაობის შესახებ |
განაცხადის აღწერა | ინფორმაცია პროგრამის მიზნის, გამოყენების ფარგლების, გამოყენებული მეთოდების, გადასაჭრელი პრობლემების კლასის, გამოყენების შეზღუდვების, ტექნიკის მინიმალური კონფიგურაციის შესახებ |
ინფორმაცია პროგრამის შემოწმების, ფუნქციონირების უზრუნველსაყოფად და კონკრეტული აპლიკაციის პირობების შესაბამისად |
|
პროგრამისტის სახელმძღვანელო | ინფორმაცია პროგრამის გამოყენების შესახებ |
ოპერატორის სახელმძღვანელო | ინფორმაცია პროგრამის შესრულებისას ოპერატორსა და კომპიუტერულ სისტემას შორის კომუნიკაციის პროცედურის უზრუნველსაყოფად |
ენის აღწერა | ენის სინტაქსისა და სემანტიკის აღწერა |
ინფორმაცია ტექნიკური აღჭურვილობის მომსახურებისას სატესტო და დიაგნოსტიკური პროგრამების გამოყენების შესახებ |
2.4. განხორციელების მეთოდისა და განაცხადის ხასიათიდან გამომდინარე, პროგრამის დოკუმენტები იყოფა ორიგინალად, დუბლიკატად და ასლად (GOST 2.102-68), რომლებიც განკუთვნილია პროგრამის შემუშავების, შენარჩუნებისა და მუშაობისთვის.
2.5. სხვადასხვა ეტაპზე შემუშავებული პროგრამული დოკუმენტების ტიპები და მათი კოდები მოცემულია ცხრილში 4.
ცხრილი 4
კოდი | Დოკუმენტის ტიპი | განვითარების ეტაპები |
|||
წინასწარი დიზაინი | ტექნიკური პროექტი | სამუშაო პროექტი |
|||
კომპონენტი | კომპლექსი |
||||
სპეციფიკაცია | |||||
ორიგინალური მფლობელების სია | |||||
პროგრამის ტექსტი | |||||
პროგრამის აღწერა | |||||
საოპერაციო დოკუმენტების სია | |||||
ფორმა | |||||
განაცხადის აღწერა | |||||
სისტემის პროგრამისტის სახელმძღვანელო | |||||
პროგრამისტის სახელმძღვანელო | |||||
ოპერატორის სახელმძღვანელო | |||||
ენის აღწერა | |||||
ტექნიკური სახელმძღვანელო | |||||
ტესტის პროგრამა და მეთოდოლოგია | |||||
განმარტებითი შენიშვნა | |||||
სხვა დოკუმენტები | |||||
ლეგენდა:
- დოკუმენტი სავალდებულოა;
- დოკუმენტი სავალდებულოა კომპონენტებისთვის, რომლებსაც აქვთ დამოუკიდებელი გამოყენება;
- დოკუმენტის შედგენის აუცილებლობა განისაზღვრება ტექნიკური მახასიათებლების შემუშავებისა და დამტკიცების ეტაპზე;
- - დოკუმენტი არ არის შედგენილი.
2.2-2.5. (შეცვლილი გამოცემა, შესწორება No1).
2.6. ნებადართულია გარკვეული ტიპის ოპერატიული დოკუმენტების გაერთიანება (საოპერაციო დოკუმენტების ჩამონათვალისა და ფორმის გარდა). ამ დოკუმენტების გაერთიანების აუცილებლობა მითითებულია ტექნიკურ მახასიათებლებში. გაერთიანებულ დოკუმენტს ენიჭება ერთ-ერთი გაერთიანებული დოკუმენტის დასახელება და აღნიშვნა.
გაერთიანებულ დოკუმენტებში უნდა იყოს მითითებული ინფორმაცია, რომელიც უნდა იყოს შეტანილი თითოეულ გაერთიანებულ დოკუმენტში.
2.7. ტექნიკური მახასიათებლების შემუშავებისა და დამტკიცების ეტაპზე განისაზღვრება პროგრამის წარმოების, კონტროლისა და მიღების მოთხოვნების შემცველი ტექნიკური მახასიათებლების შედგენის აუცილებლობა.
ტექნიკური მახასიათებლები შემუშავებულია „დეტალური დიზაინის“ ეტაპზე.
2.8. ტექნიკური მახასიათებლების შედგენის საჭიროება კომპონენტებისთვის, რომლებიც არ არის განკუთვნილი დამოუკიდებელი გამოყენებისთვის და სხვა კომპლექსებში შემავალი კომპლექსები, განისაზღვრება მომხმარებელთან შეთანხმებით.
(დამატებით შეტანილი, შესწორება No1).
ელექტრონული დოკუმენტის ტექსტი
მომზადებული კოდექსის მიერ და დამოწმებული:
ოფიციალური გამოცემა
ერთიანი პროგრამული სისტემა
დოკუმენტაცია: შ. GOST. -
M.: Standartinform, 2010 წ
GOST 19.001-77 ზოგადი დებულებები
GOST 19781-90 ტერმინები და განმარტებები.
GOST 19.101-77 პროგრამების ტიპები და პროგრამული დოკუმენტები
GOST 19.102-77 განვითარების ეტაპები
GOST 19.103-77 პროგრამებისა და პროგრამული დოკუმენტების აღნიშვნები
GOST 19.104-78 ძირითადი წარწერები
GOST 19.105-78 ზოგადი მოთხოვნები პროგრამის დოკუმენტებისთვის
GOST 19.106-78 მოთხოვნები დაბეჭდილი პროგრამის დოკუმენტებისთვის
GOST 19.201-78 ტექნიკური მახასიათებლები, მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.202-78 სპეციფიკაცია. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.301-79 ტესტის პროგრამა და მეთოდოლოგია. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.401-78 პროგრამის ტექსტი. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.402-78 პროგრამის აღწერა
GOST 19.403-79 ორიგინალური მფლობელების სია
GOST 19.404-79 განმარტებითი შენიშვნა. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.501-78 ფორმა. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.502-78 განაცხადის აღწერა. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.503-79 სისტემის პროგრამისტის სახელმძღვანელო. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.504-79 პროგრამისტის სახელმძღვანელო. მოთხოვნები GOST 19.505-79 ოპერატორის სახელმძღვანელოს შინაარსისა და დიზაინისთვის. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.506-79 ენის აღწერა. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.507-79 საოპერაციო დოკუმენტების სია
GOST 19.508-79 ტექნიკური სახელმძღვანელო. მოთხოვნები შინაარსისა და დიზაინისთვის
GOST 19.601-78 დუბლირების, აღრიცხვისა და შენახვის ზოგადი წესები
GOST 19.602-78 ბეჭდვით დამზადებული პროგრამული დოკუმენტების დუბლირების, აღრიცხვისა და შენახვის წესები. გზა
GOST 19.603-78 ცვლილებების შეტანის ზოგადი წესები
GOST 19.604-78 პროგრამულ დოკუმენტებში ცვლილებების შეტანის წესები დაბეჭდილი
ტექნიკური დავალება.
მოთხოვნები შინაარსისა და დიზაინის მიმართ
GOST 19.201-78
01.01-დან. 1980 წ
ეს სტანდარტი ადგენს კომპიუტერების, კომპლექსებისა და სისტემების პროგრამის ან პროგრამული პროდუქტის შემუშავების ტექნიკური სპეციფიკაციების აგებისა და მომზადების პროცედურას, მიუხედავად მათი მიზნისა და მოცულობის.
სტანდარტი სრულად შეესაბამება ST SEV 1627-79-ს.
1. ზოგადი დებულებები
1.1. სამუშაო პირობები შედგენილია GOST 19.106-78 შესაბამისად 11 და 12 ფორმატის ფურცლებზე GOST 2.301-68 შესაბამისად, როგორც წესი, ფურცლის ველების შევსების გარეშე. ფურცლის (გვერდის) ნომრები მოთავსებულია ფურცლის ზედა ნაწილში ტექსტის ზემოთ.
1.2. დამტკიცების ფურცელი და სათაურის გვერდი შედგენილია GOST 19.104-78 შესაბამისად.
საინფორმაციო ნაწილი (ანოტაცია და შინაარსი), ცვლილების სარეგისტრაციო ფურცელი შეიძლება არ იყოს შეტანილი დოკუმენტში.
1.3. პროგრამის ან პროგრამული პროდუქტის შემუშავების შემდგომ ეტაპებზე ტექნიკურ მახასიათებლებში ცვლილებების ან დამატებების შესატანად, გამოდის მასში დამატება. ტექნიკურ მახასიათებლებში დამატებების კოორდინაცია და დამტკიცება ხორციელდება იმავე წესით, როგორც დადგენილია ტექნიკური მახასიათებლებისთვის.
1.4. მითითების პირობები უნდა შეიცავდეს შემდეგ განყოფილებებს:
შესავალი;
· განვითარების საფუძველი;
· განვითარების მიზანი;
· მოთხოვნები პროგრამის ან პროგრამული პროდუქტის მიმართ;
· მოთხოვნები პროგრამული დოკუმენტაციის მიმართ;
· ტექნიკური და ეკონომიკური მაჩვენებლები;
· განვითარების ეტაპები და ფაზები;
· კონტროლისა და მიღების პროცედურა;
· განაცხადები შეიძლება იყოს ტექნიკურ მახასიათებლებში.
პროგრამის ან პროგრამული პროდუქტის მახასიათებლებიდან გამომდინარე, შესაძლებელია სექციების შინაარსის გარკვევა, ახალი სექციების შემოღება ან ცალკეულის გაერთიანება.
2.1. "შესავალი" განყოფილებაში მიუთითეთ დასახელება, პროგრამის ან პროგრამული პროდუქტის გამოყენების სფეროს მოკლე აღწერა და ობიექტი, რომელშიც გამოიყენება პროგრამა ან პროგრამული პროდუქტი.
(შეცვლილი გამოცემა, შესწორება No1)
2.2. განყოფილებაში "განვითარების საფუძველი" უნდა იყოს მითითებული:
· დოკუმენტ(ებ)ი, რომლის საფუძველზეც ხორციელდება შემუშავება;
· ორგანიზაცია, რომელმაც დაამტკიცა ეს დოკუმენტი და მისი დამტკიცების თარიღი;
· განვითარების თემის სახელი და (ან) სიმბოლო.
(შეცვლილი გამოცემა, შესწორება No1)
2.3. განყოფილებაში „განვითარების მიზანი“ უნდა იყოს მითითებული პროგრამის ან პროგრამული პროდუქტის ფუნქციონალური და ოპერატიული მიზანი.
2.4. განყოფილება „პროგრამის ან პროგრამული პროდუქტის მოთხოვნები“ უნდა შეიცავდეს შემდეგ ქვეგანყოფილებებს:
· ფუნქციური მახასიათებლების მოთხოვნები;
· სანდოობის მოთხოვნები;
· მოხმარების პირობები;
· მოთხოვნები ტექნიკური საშუალებების შემადგენლობასა და პარამეტრებზე;
· მოთხოვნები ინფორმაციისა და პროგრამული უზრუნველყოფის თავსებადობასთან დაკავშირებით;
· ეტიკეტირებისა და შეფუთვის მოთხოვნები;
· მოთხოვნები ტრანსპორტირებისა და შენახვის შესახებ;
· სპეციალური მოთხოვნები.
(შეცვლილი გამოცემა, შესწორება No1)
2.4.1. ქვეთავში „მოთხოვნები ფუნქციონალურ მახასიათებლებთან“ უნდა მიეთითოს მოთხოვნები შესრულებული ფუნქციების შემადგენლობის, შეყვანისა და გამომავალი მონაცემების ორგანიზების, დროის მახასიათებლების და ა.შ.
2.4.2. ქვეთავში „სანდოობის მოთხოვნები“ უნდა მიეთითოს მოთხოვნები საიმედო მუშაობის უზრუნველსაყოფად (სტაბილური მუშაობის უზრუნველყოფა, შეყვანისა და გამომავალი ინფორმაციის მონიტორინგი, მარცხის შემდეგ აღდგენის დრო და ა.შ.).
2.4.3. ქვეთავში „სამუშაო პირობები“ უნდა მიეთითოს სამუშაო პირობები (ატმოსფეროს ტემპერატურა, ფარდობითი ტენიანობა და ა.შ. შერჩეული ტიპის შესანახი საშუალებებისთვის), რომლებშიც უნდა იყოს უზრუნველყოფილი მითითებული მახასიათებლები, აგრეთვე მომსახურების სახეობა, საჭირო რაოდენობა და კვალიფიკაცია. პერსონალის.
2.4.4. ქვეთავში „ტექნიკური საშუალებების შემადგენლობისა და პარამეტრების მოთხოვნები“ მითითებულია ტექნიკური საშუალებების საჭირო შემადგენლობა, მათი ძირითადი ტექნიკური მახასიათებლების მითითებით.
2.4.5. ქვეთავში „ინფორმაციისა და პროგრამული უზრუნველყოფის თავსებადობის მოთხოვნები“ უნდა მიუთითებდეს საინფორმაციო სტრუქტურების მოთხოვნები შეყვანისა და გამომავალი და გადაწყვეტის მეთოდებზე, წყაროს კოდები, პროგრამირების ენები და პროგრამის მიერ გამოყენებული პროგრამული უზრუნველყოფა.
საჭიროების შემთხვევაში უზრუნველყოფილი უნდა იყოს ინფორმაციისა და პროგრამების დაცვა.
(შეცვლილი გამოცემა, შესწორება No1)
2.4.6. ქვეთავში „მოთხოვნები მარკირებისა და შეფუთვის შესახებ“, ზოგადად, მითითებულია პროგრამული პროდუქტის მარკირების მოთხოვნები, შეფუთვის ვარიანტები და მეთოდები.
2.4.7. ქვეთავში „ტრანსპორტისა და შენახვის მოთხოვნები“ უნდა მიეთითოს პროგრამული პროდუქტის ტრანსპორტირების პირობები, შენახვის ადგილები, შენახვის პირობები, შენახვის პირობები, შენახვის ვადები სხვადასხვა პირობებში.
2.5ა. განყოფილებაში „პროგრამული დოკუმენტაციის მოთხოვნები“ უნდა მიეთითოს პროგრამული დოკუმენტაციის წინასწარი შემადგენლობა და, საჭიროების შემთხვევაში, მისთვის სპეციალური მოთხოვნები.
(დამატებით შეტანილი, შესწორება No1).
2.5. განყოფილებაში „ტექნიკური და ეკონომიკური მაჩვენებლები“ უნდა მიეთითოს: სავარაუდო ეკონომიკური ეფექტურობა, სავარაუდო წლიური მოთხოვნა, განვითარების ეკონომიკური უპირატესობები საუკეთესო საშინაო და უცხოურ ნიმუშებთან ან ანალოგებთან შედარებით.
2.6. განყოფილებაში „განვითარების ეტაპები და ფაზები“ ჩამოყალიბებულია განვითარების აუცილებელი ეტაპები, სამუშაოს ეტაპები და შინაარსი (პროგრამული დოკუმენტების სია, რომლებიც უნდა შემუშავდეს, შეთანხმებული და დამტკიცდეს), ასევე, როგორც წესი, განისაზღვრება განვითარების ვადები და შემსრულებლები.
2.7. სექციაში „კონტროლისა და მიღების პროცედურა“ უნდა მიეთითოს ტესტების სახეები და სამუშაოს მიღების ზოგადი მოთხოვნები.
2.8. ტექნიკური მახასიათებლების დანართებში, საჭიროების შემთხვევაში, მოცემულია შემდეგი:
კვლევისა და განვითარების დამამტკიცებელი სხვა სამუშაოების ჩამონათვალი;
ალგორითმის დიაგრამები, ცხრილები, აღწერილობები, დასაბუთებები, გამოთვლები და სხვა დოკუმენტები, რომლებიც შეიძლება გამოყენებულ იქნას განვითარების დროს;
განვითარების სხვა წყაროები.
მოთხოვნები პროგრამული დოკუმენტების მიმართ,
დაბეჭდილი
GOST 19.106-78
1.5. პროგრამის დოკუმენტები შედგენილია:
A4 ფორმატის ფურცლებზე (GOST 2.301-68) - საბეჭდი ან ხელნაწერით დოკუმენტის მომზადებისას (ფორმა 1). დასაშვებია დიზაინი A3 ფურცლებზე (ფორმა 2);
A4 და A3 ფორმატის ფურცლებზე, რომლებიც გათვალისწინებულია მონაცემთა გამომავალი მოწყობილობების გამომავალი მახასიათებლებით - მანქანით დოკუმენტის წარმოებისას. დაშვებულია A4 და A3 ფორმატების შესაბამისი ფურცლების ზომებში გადახრები, რაც განისაზღვრება გამოყენებული ტექნიკური საშუალებების შესაძლებლობებით;
ტიპოგრაფიული ფორმატის ფურცლებზე - დოკუმენტის ტიპოგრაფიული მეთოდით წარმოებისას.
პროგრამული დოკუმენტის მასალები დალაგებულია შემდეგი თანმიმდევრობით:
სათაურის ნაწილი:
§ დამტკიცების ფურცელი (არ შედის დოკუმენტის ფურცლების საერთო რაოდენობაში);
§ სათაურის გვერდი (დოკუმენტის პირველი გვერდი);
§ საინფორმაციო ნაწილი:
§ ანოტაცია;
§ მთავარი ნაწილი:
§ დოკუმენტის ტექსტი (სურათებით, ცხრილებით და ა.შ.);
§ განაცხადები;
§ ტერმინების სია;
§ აბრევიატურების სია;
§ ნახატების სია;
§ ცხრილების სია;
§ საგნის ინდექსი;
§ საცნობარო დოკუმენტების სია;
§ სიმბოლოებისა და რიცხვითი კოეფიციენტების სია;
§ სარეგისტრაციო ნაწილის შეცვლა:
§ სარეგისტრაციო ფურცლის შეცვლა.
საჭიროების შემთხვევაში კეთდება დანართები, ტერმინების ნუსხები, აბრევიატურები, ფიგურები და ცხრილები, საგნის ინდექსი, საცნობარო დოკუმენტების სიები, სიმბოლოები და რიცხვითი კოეფიციენტები.
(შეცვლილი გამოცემა, შესწორება No1)
1.7. ტერმინებისა და აბრევიატურების სიები, საგნის ინდექსი, სიმბოლოების სია და რიცხვითი კოეფიციენტები უნდა იყოს შედგენილი ანბანური თანმიმდევრობით.
დარჩენილი სიები შედგენილია რიცხვების ზრდის მიხედვით.
(დამატებით შეტანილი, შესწორება No1)
2. მოთხოვნები პროგრამული დოკუმენტების მიმართ, რომლებიც შეიცავს ძირითადად უწყვეტ ტექსტს.
2.1. დოკუმენტის მშენებლობა.
2.1.1. საჭიროების შემთხვევაში დასაშვებია დოკუმენტის ნაწილებად დაყოფა. ნაწილებად დაყოფა ხორციელდება განყოფილებაზე არანაკლებ დონეზე. თითოეულ ნაწილს ცალ-ცალკე მიეწოდება. ყველა ნაწილს ენიჭება დოკუმენტის აღნიშვნა GOST 19.103-77 შესაბამისად.
ნაწილები შედგენილია ამ სტანდარტის მოთხოვნების შესაბამისად, ხოლო პირველი ნაწილის შინაარსის ბოლოს უნდა იყოს ჩამოთვლილი დარჩენილი ნაწილების სახელები.
ნებადართულია დოკუმენტში შეიტანოს პროგრამის ტექსტის ნაწილები, ფორმატირებული იმ ენის წესებით, რომელზედაც დაწერილია პროგრამის ტექსტი.
დოკუმენტის გვერდების ნუმერაცია, აგრეთვე სექციების, ფიგურების და ცხრილების ნუმერაცია ხორციელდება თითოეულ ნაწილში. თითოეული ნაწილი იწყება სათაურის გვერდით.
დაუშვებელია დოკუმენტის გვერდების ცალკე ნუმერაცია განყოფილებაში და ქვესექციაში.
დამტკიცების ფურცელი გაიცემა მთელ დოკუმენტზე პირველი ნაწილის მითითებით.
2.1.2. პროგრამული დოკუმენტის ინფორმაცია და ძირითადი ნაწილები შედგენილია ფორმა 1 ან 2, სადაც:
ველი 1 - გვერდის სერიული ნომერი;
ველი 2 - დოკუმენტის აღნიშვნა;
ველი 3 - დოკუმენტის ტექსტი;
ველი 4 - ცვლილებების ხაზი; შევსებულია GOST 19.604-78 მოთხოვნების შესაბამისად.
დოკუმენტის გვერდის ფორმატის ჩარჩო (საზღვრები) შეიძლება არ იყოს გამოყენებული.
2.1.3. რეზიუმე მოთავსებულია ცალკეულ (დანომრილ) გვერდზე სათაურით „ABSTRACT“ და არ არის დანომრილი განყოფილებად.
ანოტაციაში მითითებულია პროგრამის გამოცემა და მოკლედ ასახულია დოკუმენტის მიზანი და შინაარსი. თუ დოკუმენტი შედგება რამდენიმე ნაწილისგან, ნაწილების საერთო რაოდენობა მითითებულია ანოტაციაში.
შიგთავსში შეტანილი სახელები იწერება მცირე ასოებით. დიდი ასოები და აბრევიატურები უნდა იყოს დაბეჭდილი დიდი ასოებით.
2.1.3, 2.1.4. (შეცვლილი გამოცემა, შესწორება No1).
2.1.5. თითოეული დოკუმენტის ტექსტი, საჭიროების შემთხვევაში, იყოფა აბზაცებად, ხოლო აბზაცები ქვეპუნქტებად, მიუხედავად იმისა, იყო თუ არა დოკუმენტი ნაწილებად, ნაწილებად და ქვეპუნქტებად.
2.1.6. დოკუმენტის ტექსტის სტრუქტურული ელემენტებია განყოფილებები, ქვეგანყოფილებები, აბზაცები, ქვეპუნქტები და ჩამოთვლა.
განყოფილება - გაყოფის პირველი ეტაპი, მითითებული ნომრით და მოწოდებული სათაურით.
ქვეგანყოფილება - განყოფილების ნაწილი, რომელიც მითითებულია რიცხვით და აქვს სათაური.
პუნქტი - განყოფილების ან ქვეგანყოფილების ნაწილი, მითითებული ნომრით. შეიძლება ჰქონდეს სათაური.
ქვეპუნქტი - ნივთის ნაწილს, რომელიც მითითებულია რიცხვით, შეიძლება ჰქონდეს სათაური.
აბზაცი არის ტექსტის ლოგიკურად გამოყოფილი ნაწილი, რომელსაც არ აქვს ნომერი.
თუ დოკუმენტის ტექსტში სექციები არ არის, მისი პირველი სტრუქტურული ელემენტია აბზაცი.
დასაშვებია ტექსტის განთავსება განყოფილებისა და ქვესექციის სათაურებს შორის, ქვესექციასა და აბზაცის სათაურებს შორის.
ქვესექციების, აბზაცებისა და ქვეპუნქტების ფარგლებში შეიძლება მიეთითოს სიები, რომლებიც რეკომენდირებულია აღინიშნოს არაბული ციფრებით ფრჩხილით: 1), 2) და ა.შ. დასაშვებია ჩამონათვალის გამოკვეთა ტექსტის წინ დეფისის დაყენებით.
თითოეული სტრუქტურული ელემენტი იწყება აბზაცის აბზაცით.
(შეცვლილი გამოცემა, შესწორება No1).
2.1.7. განყოფილების სათაურები იწერება დიდი ასოებით და მოთავსებულია სიმეტრიულად ტექსტის მარჯვენა და მარცხენა საზღვრებთან მიმართებაში.
ქვესექციის სათაურები იწერება აბზაციდან მცირე ასოებით (გარდა პირველი დიდისა).
მანქანით დოკუმენტის დაბეჭდვისას დასაშვებია ქვეგანყოფილებების და აბზაცების სათაურების ჩაწერა საბეჭდ მოწყობილობაზე არსებული შრიფტით.
სათაურებში სიტყვების დეფისი დაუშვებელია. სათაურის ბოლოს წერტილი არ არის.
თუ სათაური შედგება ორი წინადადებისგან, ისინი გამოყოფილია წერტილით.
(შეცვლილი გამოცემა, შესწორება No1).
2.1.8. მანძილი სათაურსა და შემდეგ ტექსტს შორის, ასევე განყოფილებისა და ქვესექციის სათაურებს შორის უნდა იყოს ტოლი:
საბეჭდი ბეჭდვით დოკუმენტის შესრულებისას – ორი ინტერვალი;
ხელნაწერის შესრულებისას - 10 მმ;
როდესაც კეთდება მანქანით - მინიმუმ სამი შრიფტის სიმაღლე.
სექციებისა და ქვესექციებისთვის, რომელთა ტექსტი იწერება იმავე გვერდზე წინა განყოფილების ტექსტთან ერთად, მანძილი ტექსტის ბოლო სტრიქონსა და შემდგომ სათაურს შორის უნდა იყოს ტოლი:
საბეჭდი მეთოდით დოკუმენტის შესრულებისას - სამი საბეჭდი ინტერვალი;
ხელნაწერის შესრულებისას - მინიმუმ 15 მმ;
როდესაც კეთდება მანქანით - მინიმუმ ოთხი შრიფტის სიმაღლე.
სათაურის ხაზების ფუძეებს შორის მანძილი იგივეა, რაც ტექსტში.
ბეჭდვის მეთოდით დოკუმენტების გამოქვეყნებისას მითითებული დისტანციები შედგენილია პუბლიკაციების ბეჭდვის წესების მიხედვით.
2.1.9. სექციები, ქვეპუნქტები, აბზაცები და ქვეპუნქტები უნდა იყოს დანომრილი არაბული ციფრებით წერტილით.
სექციებს უნდა ჰქონდეს თანმიმდევრული ნომერი (1, 2 და ა.შ.).
განყოფილების ფარგლებში უნდა იყოს უწყვეტი ნუმერაცია ამ განყოფილებაში შემავალი ყველა ქვესექციის, პუნქტისა და ქვეპუნქტისთვის.
ქვეპუნქტების ნუმერაცია მოიცავს განყოფილების ნომერს და ამ განყოფილებაში შემავალი ქვეგანყოფილების სერიულ ნომერს, გამოყოფილი წერტილით (2.1; 3.1 და ა.შ.).
თუ არსებობს განყოფილებები და ქვეპუნქტები, წერტილის შემდეგ ქვეპუნქტის ნომერს ემატება პუნქტისა და ქვეპუნქტის რიგითი ნომერი (3.1.1, 3.1.1.1 და ა.შ.).
პროგრამული დოკუმენტის ტექსტის სტრუქტურისა და მისი სექციების, ქვესექციების, აბზაცებისა და ქვეპუნქტების ნუმერაციის მაგალითი მოცემულია დანართ 2-ში მითითებით.
(შეცვლილი გამოცემა, შესწორება No1).
2.1.10. (ამოღებულია, შესწორება No1)
2.2. დოკუმენტის ტექსტი.
2.2.1. დოკუმენტის ტექსტი უნდა იყოს მოკლე, მკაფიო, მცდარი ინტერპრეტაციის გამორიცხვით.
ტერმინები და განმარტებები უნდა იყოს ერთგვაროვანი და შეესაბამებოდეს დადგენილ სტანდარტებს, ხოლო მათი არარსებობის შემთხვევაში - ზოგადად მიღებული სამეცნიერო და ტექნიკური ლიტერატურაში და მითითებული უნდა იყოს ტერმინთა ჩამონათვალში.
2.2.2. ტექსტში სიტყვების შემოკლებები და წარწერები ილუსტრაციებში დასაშვებია GOST 2.316-68 შესაბამისად. დამატებითი აბრევიატურები, რომლებიც მიღებულია დოკუმენტში და არ შედის GOST 2.316-68-ში, უნდა იყოს მოცემული მიღებული აბრევიატურების ჩამონათვალში.
2.2.3. ცალკეული ცნებების ხაზგასასმელად დასაშვებია სიტყვებს შორის მანძილის შეცვლა, აგრეთვე ცალკეული სიტყვების ან ტექსტის ნაწილების დაბეჭდვა ძირითადი ტექსტისგან განსხვავებული შრიფტით, მაგალითად:
UNCATLG - მიუთითებს, რომ დირექტორიაში ჩანაწერი, რომელიც დაკავშირებულია წყაროს მონაცემთა ნაკრებთან, უნდა გამოირიცხოს. TO = მოწყობილობა = სია - მიუთითებს შესანახ მედიაზე, რომელზეც...ABC3-91 SYNTAX ERROR CAUSE. მითითებულია შეტყობინებაში...SYSTEM ACTION. დავალება არ არის შესრულებული...პროგრამის მოქმედებები. აუცილებელია უზრუნველყოს...
2.2.4. დოკუმენტის ტექსტის საჭირო ახსნა-განმარტებები შეიძლება იყოს სქოლიოში.
სქოლიო მითითებულია რიცხვით შრიფტის ზედა კიდეზე მოთავსებული ფრჩხილით, მაგალითად: „საბეჭდი მოწყობილობა2)“ ან „ქაღალდი5)“.
თუ სქოლიო ეხება ერთ სიტყვას, სქოლიო მოთავსებულია უშუალოდ ამ სიტყვის გვერდით, მაგრამ თუ იგი ეხება წინადადებას მთლიანობაში, მაშინ წინადადების ბოლოს. სქოლიოს ტექსტი მოთავსებულია გვერდის ბოლოს და გამოყოფილია ძირითადი ტექსტისგან 3 სმ სიგრძის ხაზით, რომელიც დახატულია გვერდის მარცხენა მხარეს.
2.3. ილუსტრაციები.
2.3.1. ილუსტრაციები შეიძლება განთავსდეს დოკუმენტის ტექსტში და (ან) დანართებში.
ილუსტრაციები, თუ მოცემულ დოკუმენტში ერთზე მეტია, დანომრილია არაბული ციფრებით მთელ დოკუმენტში.
დანართებში, ილუსტრაციები დანომრილია თითოეულ დანართში დოკუმენტის ძირითადი ტექსტისთვის დადგენილი თანმიმდევრობით.
ილუსტრაციებს შეიძლება ჰქონდეს თემატური სათაური და წარწერის ტექსტი, რომელიც ხსნის ილუსტრაციის შინაარსს.
ილუსტრაციის ზემოთ მოთავსებულია თემატური სათაური (სახელი), ქვემოთ - წარწერის ტექსტი. საილუსტრაციო ნომერი მოთავსებულია განმარტებითი მონაცემების ქვეშ.
(შეცვლილი გამოცემა, შესწორება No1).
2.4. ფორმულები.
2.4.1. დოკუმენტში ფორმულები, თუ მათგან ერთზე მეტია, დანომრილია არაბული ციფრებით; ნომერი მოთავსებულია გვერდის მარჯვენა მხარეს, ფორმულის დონეზე ფრჩხილებში.
მთელი დოკუმენტის ან მისი ნაწილების ფარგლებში, თუ დოკუმენტი იყოფა ნაწილებად, ფორმულებს აქვთ უწყვეტი ნუმერაცია.
დოკუმენტის ნაწილებად დაყოფისას, ნაწილის ნომერი მოთავსებულია ფორმულის სერიული ნომრის წინ და გამოყოფილია ბოლო წერტილიდან, მაგალითად: "ფორმულაში (1.4)."
2.4.2. ფორმულაში შემავალი სიმბოლოებისა და რიცხვითი კოეფიციენტების მნიშვნელობა მითითებული უნდა იყოს პირდაპირ ფორმულის ქვემოთ. თითოეული სიმბოლოს მნიშვნელობა იბეჭდება ახალ ხაზზე იმ თანმიმდევრობით, რომლითაც ისინი მოცემულია ფორმულაში. ტრანსკრიპტის პირველი სტრიქონი უნდა დაიწყოს სიტყვით „სად“, მის შემდეგ ორწერტილის გარეშე.
თუ პროგრამის დოკუმენტი შეიცავს ამ სიმბოლოებისა და რიცხვითი კოეფიციენტების ჩამონათვალს, ფორმულის მნიშვნელობები შეიძლება არ იყოს მოცემული.
(შეცვლილი გამოცემა, შესწორება No1).
2.4.3. ერთი და იგივე პარამეტრის განზომილება ერთ დოკუმენტში უნდა იყოს მუდმივი.
2.5.1. პროგრამულ დოკუმენტებში ნებადართულია მითითებები სტანდარტებზე (გარდა საწარმოს სტანდარტებისა), ტექნიკურ მახასიათებლებზე და სხვა დოკუმენტებზე (მაგალითად, სახელმწიფო ზედამხედველობის ორგანოების დოკუმენტები, სსრკ სახელმწიფო სამშენებლო კომიტეტის წესები და დებულებები). სტანდარტებისა და ტექნიკური მახასიათებლების მითითებისას მითითებულია მათი აღნიშვნა.
მითითება უნდა მოხდეს დოკუმენტის მთლიანობაში ან მის ნაწილებზე (დოკუმენტის აღნიშვნისა და დასახელების მითითებით, განყოფილების ან დანართის ნომერი და დასახელება). განყოფილების ან განაცხადის მითითების განმეორებისას მითითებულია მხოლოდ ნომერი.
დასაშვებია მხოლოდ დოკუმენტის და (ან) სექციების აღნიშვნა მათი სახელების მითითების გარეშე. სხვა დოკუმენტის ცალკეულ ქვეპუნქტებზე, აბზაცებსა და ილუსტრაციებზე მითითება დაუშვებელია. ნებადართულია აბზაცებთან, ილუსტრაციებთან და ცალკეულ ქვეგანყოფილებებთან დოკუმენტის შიგნით ბმულები.
(შეცვლილი გამოცემა, შესწორება No1).
2.6. მაგიდები
2.6.1. ინდიკატორების უკეთესი ხილვადობისა და შედარებადობის მისაღწევად, ციფრული მასალა ჩვეულებრივ უნდა იყოს წარმოდგენილი ცხრილის სახით.
2.6.2. ცხრილები უნდა მომზადდეს GOST 1.5-68 მოთხოვნების შესაბამისად.
ცხრილს შეიძლება ჰქონდეს სათაური, რომელიც უნდა იყოს პატარა ასოებით. დიდი ასოები და აბრევიატურები უნდა იყოს დაბეჭდილი დიდი ასოებით.
(შეცვლილი გამოცემა, შესწორება No1).
2.6.3. ცხრილების სქოლიოები განლაგებულია პირდაპირ ცხრილის ქვემოთ. Მაგალითად:
ბეჭდვისთვის გამოყენებული მონაცემთა ნაკრები
მიზანი
სტანდარტული სახელი
გამოყენებული მოწყობილობა
ინფორმაციისთვის ამობეჭდვა
SSSSSSS1) საბეჭდი მოწყობილობა2)
პროგრამის შესრულების დროს დასაბეჭდად
RRRRRRRR საბეჭდი მოწყობილობა 2)
1) ოპერაციული სისტემის კონფიგურაციისას უნდა იყოს მითითებული სახელი SSSSSSS.
2) CPU-ის შეფერხების შესამცირებლად I/O ოპერაციების გამო, შეიძლება გამოყენებულ იქნას მაგნიტური ლენტი.
2.7. შენიშვნები
2.7.1. ტექსტისა და ცხრილების შენიშვნებში მითითებულია მხოლოდ მითითება და განმარტებითი მონაცემები.
ერთი შენიშვნა არ არის დანომრილი. სიტყვა "შენიშვნის" შემდეგ დააყენეთ წერტილი.
რამდენიმე შენიშვნა უნდა იყოს დანომრილი, რათა გამოიყენოს არაბული ციფრები წერტილით. სიტყვის „შენიშვნა“ შემდეგ ჩასვით ორწერტილი.
Მაგალითად:
Შენიშვნა.
შენიშვნები: 1. 2.
2.7.2. შენიშვნების ტექსტი შეიძლება დაიბეჭდოს მხოლოდ ერთი ინტერვალით.
2.8. აბრევიატურები.
2.8.1. ტექსტში სიტყვების შემოკლებები და ილუსტრაციების ქვეშ წარწერები დაუშვებელია, გარდა:
GOST 2.316-68-ში დადგენილი აბრევიატურები და ზოგადად მიღებული რუსულ ენაზე;
აბრევიატურები, რომლებიც გამოიყენება პროგრამების, მათი ნაწილებისა და მუშაობის რეჟიმების აღსანიშნავად, ამოცანების კონტროლის ენებში, პროგრამის კონფიგურაციის ხელსაწყოებში და ა.შ., მათ შორის ლათინური ანბანის ასოებით განსაზღვრული.
თუ დოკუმენტი იყენებს სიტყვების ან სახელების აბრევიატურების სპეციალურ სისტემას, მაშინ ის უნდა შეიცავდეს მიღებული აბრევიატურების ჩამონათვალს.
(შეცვლილი გამოცემა, შესწორება No1).
2.9. აპლიკაციები
2.9.1. ილუსტრირებული მასალა, ცხრილები ან დამხმარე ტექსტი შეიძლება წარმოდგენილი იყოს დანართების სახით.
დანართები შედგენილია როგორც ამ დოკუმენტის გაგრძელება მომდევნო გვერდებზე ან გაიცემა ცალკე დოკუმენტად.
2.9.2. თითოეული აპლიკაცია უნდა დაიწყოს ახალ გვერდზე სიტყვით „დანართი“ მითითებული ზედა მარჯვენა კუთხეში და ჰქონდეს თემატური სათაური, რომელიც ტექსტის მიმართ სიმეტრიულად იწერება დიდი ასოებით.
თუ დოკუმენტში ერთზე მეტი დანართია, ყველა დანართი დანომრილია არაბული ციფრებით (ნომერი ნიშნის გარეშე), მაგალითად, დანართი 1, დანართი 2 და ა.შ.
განცხადების ცალკე დოკუმენტის სახით გაცემისას დოკუმენტის სახელწოდების ქვეშ სათაურ გვერდზე უნდა მიეთითოს სიტყვა „დანართი“, ხოლო თუ განაცხადი რამდენიმეა, მათი სერიული ნომრებიც.
ცალკე დოკუმენტის სახით გაცემული დანართები მითითებულია დოკუმენტის ნაწილად. საჭიროების შემთხვევაში, ასეთი აპლიკაცია შეიძლება შეიცავდეს "შინაარსს".
შესაძლებელია რამდენიმე აპლიკაციის გაერთიანება პროგრამის დოკუმენტის ცალკეულ ნაწილში.
(შეცვლილი გამოცემა, შესწორება No1).
2.9.4. დოკუმენტის ფურცლებისა და დოკუმენტში შემავალი დანართების ნუმერაცია უნდა იყოს უწყვეტი, გარდა იმ შემთხვევისა, როდესაც დანართები შედგენილია ცალკე დოკუმენტად.
დანართებში ილუსტრაციები და ცხრილები დანომრილია თითოეულ დანართში.
(შეცვლილი გამოცემა, შესწორება No1).
ყველა დანართი უნდა იყოს ჩამოთვლილი შიგთავსის ფურცელზე.
3. მოთხოვნები პროგრამული დოკუმენტების მიმართ, რომლებიც შეიცავს ტექსტს დაყოფილი გრაფიკებად.
3.1. გრაფიკებად დაყოფილი ტექსტის შემცველი პროგრამის დოკუმენტები, საჭიროების შემთხვევაში, იყოფა სექციებად და ქვეგანყოფილებებად, რომლებიც არ არის დანომრილი. ნებადართულია ხაზების და სვეტების განმსაზღვრელი ხაზების არ დახაზვა.
3.2. განყოფილებებისა და ქვეგანყოფილებების სახელები იწერება სათაურების სახით მცირე ასოებით (გარდა პირველი დიდისა) და ხაზგასმულია.
სათაურსა და შემდეგ ტექსტს შორის, ტექსტსა და შემდეგ სათაურს შორის და სათაურებს შორის მანძილი უნდა შეესაბამებოდეს 2.1.8 პუნქტში მითითებულ მანძილს.
3.3. დოკუმენტში შენიშვნები შედგენილია 2.7 პუნქტში მითითებული თანმიმდევრობით.
3.4. ცხრილებსა და ფორმებში, რომლებსაც აქვთ რიგები, ყველა ჩანაწერი მოთავსებულია თითოეულ რიგში ერთ რიგში.
ჩანაწერები არ უნდა გაერთიანდეს სტრიქონებისა და სვეტების განმსაზღვრელ ხაზებთან.
თქვენ უნდა დატოვოთ თავისუფალი ხაზები სექციებსა და ქვეგანყოფილებებს შორის და დიდ დოკუმენტებში, ასევე განყოფილებებსა და ქვესექციაში.
თუ ტექსტის რამდენიმე სტრიქონი იწერება დოკუმენტის სვეტში, შემდეგ სვეტებში ჩანაწერები იწყება პირველი ხაზის დონეზე. დასაშვებია ჩანაწერის განთავსება ბოლო ხაზის დონეზე, თუ ის ერთ ხაზს იკავებს.
(შეცვლილი გამოცემა, შესწორება No1).
დანართი 1
ინფორმაცია
საინფორმაციო მონაცემები GOST 19.106-78-თან შესაბამისობის შესახებ
ST SEV 2088-80
წმ. 1 GOST 19.106-78 შეესაბამება განყოფილებას. 1 და წმ. 4 (პუნქტი 4.1) ST SEV 2088-80.
წმ. 2 GOST 19.106-78 შეესაბამება განყოფილებას. 4 (პუნქტები 4.4-4.9) ST SEV 2088-80.
(დამატებით შეტანილი, შესწორება No1).
დანართი 2
ინფორმაცია
პროგრამული დოკუმენტის ტექსტის სტრუქტურა
ძირითადი ინსტრუქციები
პროგრამული დოკუმენტაციის ერთიანი სისტემა.
სსრკ სტანდარტების სახელმწიფო კომიტეტის 1978 წლის 18 დეკემბრის No3351 დადგენილებით დადგინდა შემოღების თარიღი.
01/01/1980 წლიდან
ეს სტანდარტი ადგენს ფორმებს, ზომებს, ადგილმდებარეობას და პროცედურას დამტკიცების ფურცლისა და სათაურის გვერდის შევსების პროგრამულ დოკუმენტებში ESPD სტანდარტებით, მიუხედავად მათი განხორციელების მეთოდებისა.
სტანდარტი შეესაბამება ST SEV 2088-80-ს დამტკიცების ფურცლისა და სათაურის გვერდის დიზაინთან დაკავშირებით (იხ. მითითება დანართი 1).
1. ძირითადი დებულებები
1.1. პროგრამის დოკუმენტებში დამტკიცების ფურცლისა და სათაურის გვერდის ძირითადი წარწერები მოიცავს შემდეგ სტრუქტურულ მონაცემებს:
სამინისტროს (დეპარტამენტის) დასახელება;
დოკუმენტის სათაური;
დოკუმენტის აღნიშვნა;
ინფორმაცია მონაცემთა საშუალების შესახებ, რომელზედაც წარმოდგენილია ორიგინალი;
დამტკიცების ფურცლების საერთო რაოდენობა, დოკუმენტის მოცულობა;
ინფორმაცია დეველოპერის შესახებ;
ნორმატიული კონტროლერის ვიზა;
რეგისტრაციისა და შენახვის ჩანაწერი;
ინფორმაცია ცვლილების შესახებ.
2. დამტკიცების ფურცლის ძირითადი ინსტრუქციები (LA)
2.1. დამტკიცების ფურცელი გაიცემა თითოეული პროგრამული დოკუმენტისთვის A4 ქაღალდის ფურცლებზე (GOST 2.301-68), მიუხედავად დოკუმენტის ტიპისა, რომელიც შეიძლება შესრულდეს ნებისმიერ მონაცემთა ბაზაზე.
2.2. დამტკიცების ფურცლის აღნიშვნა შედგება იმ დოკუმენტის აღნიშვნისაგან, რომელსაც ეხება დამტკიცების ფურცელი და გამოყოფილია დეფისით - LU კოდი.
დამტკიცების ფურცელი არ შედის დოკუმენტების ფურცლების საერთო რაოდენობაში.
2.3. დამტკიცების ფურცელი შეიძლება შეიცავდეს რამდენიმე ფურცელს, ამ შემთხვევაში თითოეული ფურცელი დანომრილია. პირველ ფურცელზე მითითებულია დამტკიცების ფურცელში შეტანილი ფურცლების საერთო რაოდენობა.
მეორე და შემდგომი დამტკიცების ფურცლები შედგენილია განყოფილების შესაბამისად. 1 GOST 19.106-78, ხოლო "დოკუმენტის ტექსტი" ველში მოცემულია იმ პირთა პოზიციები და ხელმოწერები, რომლებიც არ ჯდება დამტკიცების ფურცლის პირველ ფურცელზე.
2.4. დამტკიცების ფურცელი შედის სპეციფიკაციაში დამტკიცებული დოკუმენტის შემდეგ და ინახება საწარმოში, რომელსაც აქვს ორიგინალი დოკუმენტი.
სპეციფიკაციის დამტკიცების ფურცელი ასევე შედის ამ სპეციფიკაციაში.
დამტკიცების ფურცლის ასლები ეგზავნება მომხმარებელს და დედა კომპანიას.
დამკვეთის სპეციალური ნებართვით, დამტკიცების ფურცელი შეიძლება გაიგზავნოს სხვა ორგანიზაციებს.
2.5. დამტკიცების ფურცელი ივსება ნახაზზე ნაჩვენები ფორმის მიხედვით:
ველი 1 - სამინისტროს ან დეპარტამენტის დასახელება, რომლის სისტემაც მოიცავს ორგანიზაციას, რომელმაც შეიმუშავა ეს დოკუმენტი.
შევსებულია მომხმარებლის მოთხოვნით.
1-ლი ველის ზემოთ, ზედა მარჯვენა კუთხეში, საჭიროების შემთხვევაში, მოთავსებულია სპეციალური ნიშანი (საიდუმლო შტამპი, მითითება „არ ამოიღო საწარმოდან“ და ა.შ.);
ველი 2 - ველის მარცხენა მხარეს - იმ პირთა პოზიციები და ხელმოწერები, რომლებმაც დაამტკიცეს დოკუმენტი დამკვეთის ორგანიზაციიდან, საჭიროების შემთხვევაში, ველის მარჯვენა მხარეს - იმ პირთა პოზიციები და ხელმოწერები, რომლებმაც დაამტკიცეს დოკუმენტი. დეველოპერის ორგანიზაცია.
საკოორდინაციო და დამმტკიცებელი ორგანიზაციები, აგრეთვე თანამდებობის პირების კონკრეტული ხელმოწერები რეგულირდება სამინისტროებისა და დეპარტამენტების მიერ;
დოკუმენტის სათაური შეიძლება გამოტოვდეს ან შერწყმული იყოს პროგრამის სათაურთან;
მონაცემთა საშუალების ტიპი მითითებულია მხოლოდ იმ შემთხვევაში, თუ დოკუმენტი შესრულებულია მონაცემთა საშუალებებზე;
ველი 5 - დამტკიცების ფურცლების საერთო რაოდენობა, მაგალითად, "ფურცლები 3". ერთი ფურცლისთვის მე-5 ველი არ არის შევსებული;
ველი 6 - ველის მარჯვენა მხარეს - ორგანიზაციის ხელმძღვანელის პოზიციები და ხელმოწერები, რომელმაც გასცა დოკუმენტი, განყოფილების ხელმძღვანელი, რომელმაც შეიმუშავა დოკუმენტი, განვითარების მენეჯერი (დეველოპერი), მათ, ვინც შეიმუშავა დოკუმენტი და ნორმატიული ინსპექტორი.
თითოეული ხელმოწერის მარჯვნივ არის დოკუმენტზე ხელმომწერის ინიციალები და გვარი, ხელმოწერის ქვემოთ კი ხელმოწერის თარიღი.
თუ შესატყვისი ხელმოწერების დიდი რაოდენობაა, ისინი მოთავსებულია მე-2 ველის მარცხენა მხარეს ან მე-6 ველის მარცხენა მხარეს.
სხვა თანამდებობის პირების ვიზები, თუ ისინი მოთხოვნილ იქნა დოკუმენტზე, მოთავსებულია LU-ს შესატან ველში;
ველი 9 - ცვლილებების ხაზი GOST 19.604-78 შესაბამისად;
ველი 10 - დოკუმენტის წერილი.
LU-ს შევსების მაგალითი მოცემულია მითითების დანართ 2-ში. დანართში ხელმოწერების რაოდენობა მოცემულია პირობითად.
3. სათაურის გვერდის ძირითადი ინსტრუქციები
3.1. სატიტულო გვერდი ივსება LU-სთვის დადგენილი ფორმისა და წესების შესაბამისად, ხოლო:
ველი 1 - ივსება მომხმარებლის მოთხოვნით;
ველი 2 - არ შეავსოთ;
ველი 3 - პროგრამის ან პროგრამული პროდუქტის სრული დასახელება (მთავრული ასოებით), დოკუმენტის დასახელება და ტიპი.
დოკუმენტის სათაური შეიძლება გამოტოვდეს ან შერწყმული იყოს პროდუქტის სათაურთან. დასაშვებია პროგრამის ან პროგრამული პროდუქტის შემოკლებული სახელწოდების მითითება;
ველი 4 - დოკუმენტის აღნიშვნა და მონაცემთა გადამზიდველის ტიპის მითითება.
შენახვის საშუალების ტიპი მითითებულია მხოლოდ იმ შემთხვევაში, თუ პროგრამული დოკუმენტი შესრულებულია შენახვის საშუალებებზე;
ველი 5 - მიუთითეთ დოკუმენტის მოცულობა;
ველი 6 - არ შეავსოთ;
ველი 7 - დოკუმენტის გამოქვეყნების (დამტკიცების) წელი (სიტყვის „წელი“ ან „y“ მითითების გარეშე);
ველი 8 - აღრიცხვისა და შენახვის ნიშანი GOST 19.601-78 შესაბამისად;
ველი 9 - ცვლილებების ხაზი GOST 19604-78 მიხედვით;
ველი 10 - დოკუმენტის წერილი.
3.2. ზედა მარცხენა კუთხეში სათაურის გვერდზე უნდა იყოს შემდეგი წარწერა:
დამტკიცებულია--------------------- აღნიშვნა LU
სათაურის გვერდის შევსების მაგალითი მოცემულია მითითებით დანართ 3-ში.
4. ძირითადი წარწერები დოკუმენტის ტექსტში.
დანართი 1
ინფორმაცია
საინფორმაციო მონაცემები GOST 19.104-78-თან შესაბამისობის შესახებ
ST SEV 2088-80
წმ. 1 და 2 GOST 19.104-78 შეესაბამება განყოფილებას. 2 ST SEV 2088-80
წმ. 3 GOST 19.104-78 შეესაბამება განყოფილებას. 3 ST SEV 2088-80
დანართი 2
ინფორმაცია
დამტკიცების ფურცლის შევსების მაგალითი
შეთანხმდნენ
ცენტრალური კლინიკური საავადმყოფოს ხელმძღვანელი
(ხელმოწერა) A.A. Petrov
მე დავამტკიცე
Განყოფილების უფროსი
(ხელმოწერა) N. N. Sizov
მანქანების ოპერაციული სისტემა
ჩამტვირთავი
პროგრამისტის სახელმძღვანელო
დამტკიცების ფურცელი
A.V.00001-01 33 01-1-LU
(საწყობის ტიპი)
შეთანხმდნენ
სკ-ის უფროსი
(ხელმოწერა) I. I. Pavlov
ქარხნის მთავარი ინჟინერი
(ხელმოწერა) A. A. Ivanov
წარმომადგენლები
დეველოპერი კომპანია
Მთავარი ინჟინერი
NIIavtomatika
(ხელმოწერა) A. V. Basov
მე-12 დეპარტამენტის უფროსი
(ხელმოწერა) G. F. Sizov
განვითარების განყოფილების უფროსი
(ხელმოწერა) L. A. სოკოლოვი
შემსრულებელი
(ხელმოწერა) A. M. Pashin
სტანდარტული კონტროლერი
(ხელმოწერა) გ.ვ.გრომოვა
დანართი 3
ინფორმაცია
სათაურის ფურცლის შევსების მაგალითი
დამტკიცებულია
A.V.00001-01 33 01-1-LU
ერთიანი ელექტრონული გამოთვლითი სისტემა
მანქანების ოპერაციული სისტემა
ჩამტვირთავი
პროგრამისტის სახელმძღვანელო
A.V.00001-01 33 01-1
(საწყობის ტიპი)
| | | შემდეგი ლექცია ==> პროგრამებისა და პროგრამული დოკუმენტაციის შემუშავების, შემუშავებისა და მიმოქცევის ურთიერთდაკავშირებული წესების დაწესება. ESPD სტანდარტები ადგენს მოთხოვნებს, რომლებიც არეგულირებს პროგრამების შემუშავებას, შენარჩუნებას, წარმოებას და ექსპლუატაციას, რაც უზრუნველყოფს:
პროგრამის შენარჩუნება მოიცავს პროგრამის ფუნქციონირების, განვითარებისა და გაუმჯობესების ანალიზს, ასევე მასში ცვლილებების შეტანას შეცდომების აღმოსაფხვრელად. ვინაიდან ESPD არის GOST-ების ნაკრები, ამჟამად მისი გამოყენება რუსეთის ფედერაციის ტერიტორიაზე მხოლოდ საკონსულტაციო ხასიათისაა, ანუ ESPD გამოიყენება ნებაყოფლობით საფუძველზე (თუ სხვა რამ არ არის გათვალისწინებული ხელშეკრულებით, ხელშეკრულებით, ინდივიდუალური კანონებით, სასამართლოთი. გადაწყვეტილება და ა.შ.). ენციკლოპედიური YouTube1 / 3 პანელის შენობის გაანგარიშება ვებინარი: Advance Steel 2018-ის ახალი ფუნქციები ლითონის კონსტრუქციების დიზაინისთვის მასტერკლასი #2 “Autodesk Fusion 360 - ერთიანი გარემო ინოვაციური დიზაინისთვის სუბტიტრებიკლასიფიკაციაESPD სტანდარტები იყოფა ცხრილში ნაჩვენები ჯგუფებად. ESPD-ში შეტანილი სტანდარტების სია
სტანდარტების ნაკრები ავტომატური სისტემებისთვის (KSAS)პროგრამული დოკუმენტაციის ერთიანი სისტემა (USPD) არის პროგრამული დოკუმენტაციის სტანდარტების შიდა ნაკრები. პროფესიულ ხალხურ ენაზე მას ასევე უწოდებენ "მეცხრამეტე სტუმარს", რაც მთლად სწორი არ არის, რადგან საუბარია არა ერთ, არამედ 30 სხვადასხვა მარეგულირებელ და ტექნიკურ დოკუმენტზე. ძირითადად, ESPD სტანდარტები შეიცავს მოთხოვნებს პროგრამის სასიცოცხლო ციკლის სხვადასხვა ეტაპზე აღწერის დოკუმენტების შემადგენლობის, შინაარსისა და შესრულების შესახებ. გარდა ამისა, რამდენიმე დოკუმენტი ეთმობა დოკუმენტაციის შენახვისა და განახლების პროცედურას. ESPD სტანდარტები პრაქტიკულად მოკლებულია მეთოდოლოგიურ კომპონენტს. ისინი არ უხსნიან დეველოპერს, თუ როგორ უნდა დაწერონ დოკუმენტაცია, რათა ის იყოს სასარგებლო, გასაგები, ინფორმატიული, მოსახერხებელი და ა.შ. მართალია, თითოეულ განყოფილებაზე ნათქვამია, რა ინფორმაცია უნდა იყოს წარმოდგენილი მასში. ESPD სტანდარტები მიღებულ იქნა 70-იანი წლების ბოლოს და ჩვენამდე მოვიდა ორიგინალთან ახლოს. ისინი ასახავს უწყებრივი კომპიუტერული ცენტრების პრაქტიკას, სადაც მუშაობდნენ დიდი კომპიუტერები. ადამიანის ურთიერთქმედება კომპიუტერულ სისტემასთან მაშინ სტრუქტურირებული იყო სრულიად განსხვავებულად, ვიდრე ახლაა და განხორციელდა მოცულობითი დისტანციური მართვის, მუშტიანი ბარათების და ამონაბეჭდების მეშვეობით და "უბრალო მოკვდავებისთვის" გამოყენებითი პრობლემების გადასაჭრელად, ასევე კვალიფიციური პერსონალის შუამავლობით. . მჭირდება ვრცლად ახსნა, რამდენად მოძველებულია ეს სტანდარტები? საკმარისია ითქვას, რომ მათ არ იციან ისეთი გავრცელებული დოკუმენტები, როგორიცაა მომხმარებლის სახელმძღვანელო და ადმინისტრატორის სახელმძღვანელო. და მაინც, ისინი აგრძელებენ აქტიურად გამოყენებას. ფორმალურად, "მეცხრამეტეს" აქვს თანამედროვე ალტერნატივა. ზოგიერთი ISO/IEC სტანდარტი სისტემური და პროგრამული უზრუნველყოფის ინჟინერიის სფეროში თარგმნილია რუსულ ენაზე და მიღებულია რუსეთში ეროვნულ სტანდარტებად. მაგრამ მსხვილი მომხმარებლები, მათ შორის სამთავრობო მომხმარებლები, არ ჩქარობენ მათზე გადასვლას. ეს შეიძლება აიხსნას მათი ინერციით (ან ტრადიციისადმი ერთგულებით, როგორც თქვენ გირჩევნიათ), მაგრამ მხოლოდ ნაწილობრივ. ფაქტია, რომ თითოეული ESPD სტანდარტი, მცირე (მაქსიმუმ სამი გვერდიანი) მოცულობით, საკმაოდ ფორმალური და შესაბამისად ადვილად შესამოწმებელიმოთხოვნები დოკუმენტის ან დოკუმენტაციის ნაკრებისთვის. მკაცრად რომ ვთქვათ, ეს ხელს არ უშლის დოკუმენტაციის შემქმნელს დაწეროს სწორად ფორმატირებული სისულელეები. მაგრამ რადგან ESPD მკაფიოდ განსაზღვრავს, თუ რა უნდა შედგებოდეს შედეგი და როგორი უნდა იყოს ის, ჩვენ შეგვიძლია დაუყოვნებლივ უარვყოთ ქაღალდის დასტა, რომელიც არ ჯდება ამ ჩარჩოებში. ეს მნიშვნელოვნად ამარტივებს დოკუმენტაციის წარდგენისა და მიღების ამოცანას როგორც მომხმარებლისთვის, ასევე კონტრაქტორისთვის. ISO/IEC სტანდარტები, პირიქით, შეიცავს არსებითი ხასიათის ბევრ გონივრულ წესს, მაგრამ ძნელი წარმოსადგენია მათი ფორმალური გადამოწმების პროცედურა. თუმცა, არავინ იწუხებს სტანდარტების ორივე ნაკრების ერთდროულად გამოყენებას; საბედნიეროდ, ისინი ეხება დოკუმენტაციის სხვადასხვა ასპექტს და პრაქტიკულად არ ეწინააღმდეგება ერთმანეთს. მარეგულირებელი და ტექნიკური დოკუმენტების შემადგენლობა
სტანდარტების შეძენა
კომპიუტერული დახმარება Olympus |
