1. Якщо це необхідно, ПЗ має бути захищено від впливу з боку осіб, які не мають спеціаль­ного допуску.

Перед початком роботи з ПЗ користувач одержує відповідний допуск до роботи.

Примітка. Під час запуску ПЗ треба робити запит на введення даних облікового запису користувача. У разі кількох невдалих спроб введення даних облікового запису ПЗ повинно закриватися і має бути зроблено запис у журнал реєстра­ції подій з ідентифікацією події.

    1. Має бути забезпечено цілісність ПЗ і реалізовано методи автоматичного контролю цілісності ПЗ.

  1. Оцінювання відповідності програмного забезпечення

    1. Оцінювання відповідності ПЗ проводять за результатами випробування.

    2. ПЗ треба застосовувати тільки за його лризначеністю.

    3. ПЗ має відповідати вимогам цього стандарту.

    4. Алгоритми, що реалізують функції ПЗ, мають відповідати вимогам відповідних нор­мативних документів. Функції ПЗ мають бути незмінними і такими, щоб їх можна було пере­вірити.

    5. У сфері поширення державного метрологічного контролю і нагляду можна застосову­вати тільки автентифіковане ПЗ. Факт використання результатів, отриманих за застосування та­кого ПЗ, має бути очевидним і однозначним.

Автентифікацію ПЗ може бути проведено за умови випробування аналогічного ПЗ (з одна­ковою назвою, версією, розробленого одним і тим самим розробником) та внесенням його до реєстру.

  1. Автентифікацію ПЗ треба здійснювати одним з таких способів:

  1. побайтове порівняння із затвердженим ПЗ;

  2. застосування процедур вироблення ЕЦП за даними, які є складниками ПЗ, що їх було випробувано, за застосування особистого ключа підпису. Під час перевірки ЕЦП треба засто­совувати відкритий ключ перевірки підпису, що належить організації, яка засвідчила випробу­ване ПЗ.

  1. ПЗ повинно мати контрольовану однозначну ідентифікацію.

Примітка. Алгоритм ідентифікації є частиною контрольованої програми і має бути захищеним. Ідентифікація повин­на здійснюватися під час запуску ПЗ або за командою користувача.

    1. Після затвердження ПЗ не може бути змінено без повідомлення органу, що проводив його випробування.

    2. Для затверджених ЗВТ треба застосовувати тільки затверджене ПЗ.

    3. За внесення будь-яких змін має бути проведено затвердження нового ПЗ, під час якого вноситься нова програмна ідентифікація.

    4. Якщо під час проведення випробування ПЗ було виявлено невідповідність вимогам, то результат випробування визнають як негативний. Такий результат відповідає низькому ступеню відповідності.

    5. Якщо немає виявлених невідповідностей, результат випробування ПЗ визнають як по­зитивний. Такий результат відповідає середньому або високому ступеню відповідності.

    6. У разі негативного результату випробування ПЗ всю документацію треба повертати розробнику ПЗ для усунення виявлених недоліків.

    7. У разі позитивного результату випробування ПЗ розробникові має бути видано ате­стат, форму якого наведено в додатку А. Назву, версію ПЗ має бути занесено до реєстру, копію атестата зберігає організація, що проводила його випробування.

    8. Результати випробування поширюються тільки на конкретну версію випробуваного ПЗ.

  1. Документація затвердженого програмного забезпечення

    1. ПЗ повинно мати комплект документації згідно з ЄСПД.

    2. Перелік програмних документів та їхній зміст, необхідні для розроблення, виготовлення, супроводження та експлуатації, наведено в таблиці 1. Ці документи необхідно також надавати для проведення випробування ПЗ.

Таблиця 1 — Перелік та зміст програмних документів

Програмний документ

Зміст програмного документа

Технічне завдання

Сфера застосування і призначеність, технічні, техніко-економічні й спеціальні вимоги, стадії та терміни розроблення

Пояснювальна записка

Схема алгоритму (алгоритмів), загальний опис функціювання, обґрунтування прийнятих технічних і техніко-економічних рішень; опис і характеристики точності реалізованих розрахункових алгоритмів; опис методики ідентифікації; опис методів захисту і реалізо­ваних даних

Опис ПЗ

Відомості про логічну структуру і функціювання; опис функцій, що виконуються, зокрема й послідовність оброблення даних; опис типовизначальних і конструктивних параметрів

Текст ПЗ

Запис вихідного коду з необхідними коментарями

Настанова системного адміністратора

Відомості для перевірки, забезпечення функціювання і налаштування на умови конкретного застосування

Настанова користувача

Відомості для експлуатації, зокрема й опис інтерфейсів користувача, всіх меню і діалогів; характеристики системних апаратних засобів



  1. Допустимо об’єднувати окремі програмні документи (за винятком технічного завдання). Необхідність об'єднання цих документів зазначають у технічному завданні. Об'єднаному докумен­ту надають назву та познаку одного з об’єднуваних документів. Об'єднаний документ повинен містити всі відомості з об’єднаних документів.

  2. «Технічне завдання» треба розробляти згідно з ГОСТ 19.201.

  3. «Пояснювальна записка» має містити такі розділи:

  • «Вступ», у якому зазначають назву ПЗ, умовну познаку розробки, а також документи, на підставі яких проводять розроблення;

  • «Сфера застосування і призначеність»;

  • «Технічні характеристики». Цей розділ повинен містити такі підрозділи:

  1. поставлення 'завдання на розроблення ПЗ, опис застосованих математичних методів і, за необхідності, опис допущень і обмежень, пов'язаних з вибраними математичними моделями;.

  2. опис алгоритмів і функціювання, обґрунтування схем вибору алгоритму розв’язання задачі, можливі взаємодії з іншим ПЗ й апаратними засобами;

  3. опис і обґрунтування вибору методу організації вхідних і вихідних даних;

  4. опис і обґрунтування вибору складу технічних і апаратних засобів на підставі проведе­них обчислень і аналізу;

  5. опис методики ідентифікації.ПЗ;

  6. опис і обґрунтування вибору методів і засобів захисту ПЗ і даних;

  • «Очікувані техніко-економічні показники». В цьому розділі подають техніко-економічні по­казники, що обґрунтовують вибраний варіант технічного рішення;

  • «Джерела інформації», в якому наводять перелік науково-технічних публікацій, норматив­них документів та інших документів, на які є посилання в основному тексті.

До «Пояснювальної записки» може бути долучено додатки. Додатки можуть містити таблиці, обґрунтування, методики, обчислення та інші документи, що застосовують під час розробляння.

  1. «Опис ПЗ» повинен містити такі розділи:

  • «Сфера застосування і призначеність», у якому має бути зазначено відомості про сферу застосування і призначеність та можливості ПЗ, його основні характеристики, обмеження, що накладають на сферу застосування;

  • «Вимоги до застосування», в якому зазначають вимоги до функціювання ПЗ (вимоги до необхідних для забезпечення функціювання технічних і апаратних засобів, інших ПЗ, загальні ха­рактеристики вхідної і вихідної інформації, опис виконуваних функцій, зокрема послідовність об­роблення даних, опис типовизначальних і конструктивних параметрів, а також, за необхідності, вимоги організаційного, технічного і технологічного характеру);

  • «Опис задачі», в якому має бути наведено визначення задач і методи їх розв’язання;

  • «Вхідні й вихідні дані», в якому має бути наведено відомості про вхідні й вихідні дані.

Залежно від особливостей ПЗ допустимо об'єднувати окремі розділи і вводити додаткові. У додатках може бути викладено довідкові матеріали (рисунки, таблиці, графіки, приклади тощо).

  1. «Текст ПЗ» розробляють згідно зі специфікацією мови програмування, якою написано ПЗ, з необхідними коментарями за текстом документа.

«Текст ПЗ» необхідний лише для випробування за високої жорсткості випробування ПЗ.

  1. «Настанова для системного адміністратора» має містити такі розділи:

  • «Загальні відомості про ПЗ», у якому має бути зазначено сферу застосування і призна- ченість, функції, відомості про технічні й програмні засоби, що забезпечують функціювання ПЗ;

  • «Структура ПЗ», в якому має бути наведено відомості про структуру, її складові частини, про зв'язок між складовими частинами і про зв’язок з іншими ПЗ;

  • «Настроювання і перевірка ПЗ», в якому має бути наведено опис дій щодо настроюван­ня ПЗ згідно з умовами конкретного застосування і перелік засобів перевірки та тестування, що надають загальний висновок про коректність функціювання;

  • «Додаткові можливості», в якому наводять опис додаткових розділів функційних можли­востей ПЗ і методи їх застосування;

  • «Повідомлення системному адміністратору», в якому має бути наведено тексти повідом­лень, які видає ПЗ адміністратору під час настроювання, перевірки, а також під час виконання ПЗ, опис їх змісту і дії, що необхідно здійснювати відповідно до цих повідомлень.

Залежно від особливостей ПЗ допустимо об’єднувати окремі розділи й залучати додаткові. В обґрунтованих випадках допустимо розділ «Додаткові можливості» не наводити, а в назві розділів вилучати слово «програма» або заміняти його на назву ПЗ.

Документа «Настанова для системного адміністратора» може не бути, якщо наведені в ньо­му відомості не використовують під час експлуатації ПЗ.

  1. «Настанова для користувача» має містити такі розділи:

  • «Призначеність», у якому треба зазначити відомості про призначеність ПЗ й інформацію, достатню для розуміння функцій ПЗ під час його експлуатації;

  • «Загальні умови», в якому має бути наведено відомості про умови, необхідні для забез­печення функціювання ПЗ;

  • «Експлуатація програми», в якому ійає бути зазначено послідовність дій користувача, що забезпечує запуск, виконання і закінчення роботи з ПЗ, наведено опис функцій, формату і мож­ливих варіантів команд, за допомогою яких користувач здійснює завантаження і виконання про­грами, а також реакцію ПЗ на ці команди, опис інтерфейсів користувача, всіх меню і діалогів;

  • «Повідомлення», в якому має бути наведено тексти повідомлень, що їх видає ПЗ корис­тувачеві під час виконання, опис їх змісту і дії, які необхідно здійснювати за цими повідомлення­ми (дії користувача в разі збоїв, можливості повторного запуску тощо).

    1. Текстову інформацію в програмних документах треба оформлювати згідно з ДСТУ 1.5 і ДСТУ 4302.

    2. Графічну інформацію в програмних документах треба виконувати згідно з ГОСТ 19.701.

  1. ВИПРОБУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

    1. Рівні випробування програмного забезпечення

      1. Вимоги до ПЗ під час випробування залежать від ступеня жорсткості випробування і необхідного рівня захисту ПЗ та ступеня відповідності ПЗ затвердженому.

Встановлено три рівні для кожної з цих характеристик: низький, середній і високий.

  1. Установлення відповідного рівня жорсткості випробування під час затвердження здійснює уповноважений орган, що проводить випробування ПЗ. Рівень захисту і ступінь відпо­відності перевіряють відповідно до таких вимог:

  • для ПЗ і ЗВТ з ПЗ, що застосовують у сфері державного метрологічного нагляду і контролю: — жорсткість випробування має бути не нижча середньої;якщо результати оброблення даних зберігають Для подальшого використання, то рівень захисту має бути високим, інакше — не нижчим середнього;

  • ступінь відповідності має бути не нижчим середнього;

  1. для ПЗ і ЗВТ з ПЗ, що застосовують поза сферою державного метрологічного нагляду і контролю:

  • жорсткість випробування треба вибирати залежно від сфери застосування, враховуючи можливий вплив ЗВТ і ПЗ ЗВТ на здоров’я людини, екологію або фінансові розрахунки зі споживачами електроенергії, газу, води, тепла тощо;

  • рівень захисту і ступінь відповідності мають відповідати вимогам технічного завдання. Під час встановлення рівня захисту треба враховувати особливості застосування, через що вимоги до ПЗ можна встановлювати за різного обсягу.

5.1.3 Під час перевірки ПЗ, що застосовують у сфері державного метрологічного контролю і нагляду (наприклад, під час повірки ЗВТ), перевіряють відповідність рівня захисту ПЗ і ступінь відповідності, встановлений під час затвердження ПЗ, з урахуванням вимог 4.2 і 4.3.

  1. Рівень захисту програмного забезпечення

    1. Захист ПЗ ЗВТ означає вжиття адекватних заходів, направлених на запобігання нена­вмисним або навмисним його змінам. Рівень захисту впливає на технічне рішення щодо ЗВТ і тому має бути враховано, головним чином, розробником ПЗ і розробником ЗВТ з ПЗ.

    2. Установлено такі рівні захисту ПЗ:

  • низький рівень захисту, якщо захисту від ненавмисних або навмисних змін немає;

  • середній рівень захисту, якщо є захист від ненавмисних і навмисних змін за використання загальнодоступних програмних засобів;

  • високий рівень захисту, якщо є захист від ненавмисних і навмисних змін за застосування спеціальних, складних ПЗ або технічних засобів.