Автоматизовані системи терміни та визначення. Вимоги до організаційного забезпечення АСУ

ГОСТ 24.104-85 Автоматизовані системи керування. Загальні вимоги (Розділ 3 замінено на ГОСТ 34.603-92) Розділ 3 замінено на ГОСТ 34.603-92Постановою Державного комітету СРСР за стандартами від 20 грудня 1985 р. № 4632 термін запровадження встановлено

з 01.01 1987 р.

Цей стандарт поширюється на автоматизовані системи управління (АСУ) всіх видів (крім загальнодержавних) та встановлює загальні вимоги до АСУ в цілому, функцій АСУ, підготовленості персоналу та видів забезпечення АСУ, безпеки та ергономіки, види та порядок проведення випробувань при введенні АСУ у дію, комплектність АСУ, гарантії.

Стандарт не встановлює вимог до АСУ, визначених специфікою об'єктів управління. Ці вимоги формулюються у технічному завданні створення чи розвиток кожної АСУ чи інших нормативно-технічних документах відомства замовника АСУ.

Додаткові вимоги до АСУ технологічними процесами, АСУ підприємствами, виробничими та науково-виробничими об'єднаннями, галузевими АСУ встановлено в обов'язкових додатках 1-3 відповідно.

У довідковому додатку 4 наведено пояснення до деяких термінів, які застосовуються у стандарті.

1. ВИМОГИ ДО АСУ

1.1. Вимоги до АСУ загалом

1.1.1. АСУ будь-якого виду має відповідати вимогам цього стандарту, вимогам технічного завдання на її створення чи розвиток (далі – ТЗ на АСУ), а також вимогам нормативно-технічних документів, які діють у відомстві замовника АСУ.

1.1.2. Введення в дію АСУ має призводити до корисних техніко-економічних, соціальних або інших результатів, наприклад:

• зниження чисельності управлінського персоналу;
• підвищення якості функціонування об'єкта керування;
• підвищення якості управління та ін.

1.1.3. Конкретний зміст вимог щодо пп. 1.1.2, 1.1.5-1.1.11, 1.2, 1.3, 1.4.2, 1.4.3, 1.4.6, 1.4.9, 1.5.2, 1.5.4, 1.5.6, 1.5.7, 1.6. 2, 1.6.6, 1.6.12, 1.7.2, 1.7.3 встановлюють у ТЗ на АСУ.

1.1.4. АСУ має забезпечувати досягнення цілей її створення (розвитку), встановлених у ТЗ на АСУ.

1.1.5. В АСУ має бути забезпечено сумісність між її частинами, а також з автоматизованими системами (АС), взаємопов'язаними з даною АСУ.

У випадках, коли АСУ або сукупність АСУ створено на базі обчислювальної мережі, для забезпечення сумісності між елементами такої мережі повинні бути застосовані системи протоколів багаторівневої взаємодії.

1.1.6. АСУ загалом та всі види її забезпечення мають бути пристосовані до модернізації, розвитку та нарощування в межах вимог, зазначених у ТЗ на АСУ.

1.1.7. Надійність АСУ загалом та кожної її автоматизованої функції має бути достатньою для досягнення встановлених цілей функціонування системи за заданих умов застосування.

1.1.8. Адаптивність АСУ має бути достатньою для досягнення встановлених цілей її функціонування у заданому діапазоні змін умов застосування.

1.1.9. В АСУ мають бути передбачені контроль правильності виконання автоматизованих функцій та діагностування, із зазначенням місця, виду та причини виникнення порушень правильності функціонування АСУ.

1.1.10. В АСУ, що мають вимірювальні канали, має бути передбачена можливість контролю метрологічних характеристик вимірювальних каналів.

1.1.11. В АСУ мають бути передбачені заходи захисту від неправильних дій персоналу, що призводять до аварійного стану об'єкта чи системи управління, від випадкових змін та руйнування інформації та програм, а також від несанкціонованого втручання.

1.1.12. Будь-яка інформація, що надходить до АСУ, вводиться в систему одноразово за допомогою одного вхідного каналу, якщо це не призводить до невиконання вимог, встановлених у ТЗ на АСУ (за надійністю, достовірністю тощо).

1.1.13. Вихідна інформація одного й того ж смислового змісту має бути сформована в АСУ одноразово, незалежно від кількості адресатів.

1.1.14. Інформація, що міститься в базах даних АСУ, має бути актуалізована відповідно до періодичності її використання під час виконання функцій системи.

1.1.15. АСУ має бути захищена від витоку інформації, якщо це обумовлено у ТЗ на АСУ.

1.1.16. Найменування АСУ має включати найменування виду АСУ та об'єкта управління.

Наприклад:

• АСУТП нагрівання металу у методичній печі;
• організаційно-технологічна АСУ цехом №5;
• АСУП заводу «Серп та молот»

1.2. Вимоги до функцій АСУ

1.2.1. АСУ у необхідних обсягах має автоматизовано виконувати:

• збір, обробку та аналіз інформації (сигналів, повідомлень, документів тощо) про стан об'єкта управління;
• вироблення керуючих впливів (програм, планів тощо);
• передачу керуючих впливів (сигналів, вказівок, документів) на виконання та її контроль;
• реалізацію та контроль виконання керуючих впливів;
• обмін інформацією (документами, повідомленнями тощо) із взаємопов'язаними автоматизованими системами.

1.2.2. Склад автоматизованих функцій (завдань, комплексів завдань - далі функцій) АСУ повинен забезпечувати можливість керування відповідним об'єктом відповідно до будь-якої з цілей, встановлених у ТЗ на АСУ.

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

1.3. Вимоги до підготовленості персоналу АСУ

1.3.1. Кваліфікація персоналу АСУ має забезпечувати ефективне функціонування системи у всіх заданих режимах.

1.3.2. Персонал АСУ має бути підготовлений до виконання своїх обов'язків відповідно до інструкцій організаційного забезпечення.

1.3.3. Кожна особа, яка входить до складу персоналу АСУ, повинна застосовувати відповідні інформаційні моделі та працювати з технічними засобами, що ним використовуються, та документацією, що визначає порядок його діяльності.

1.4. Вимоги до технічного забезпечення АСУ

1.4.1. Комплекс технічних засобів АСУ має бути достатнім до виконання всіх автоматизованих функцій АСУ.

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

1.4.3. АСУ, що тиражуються, та їх частини повинні будуватися на базі уніфікованих технічних засобів.

1.4.4. Технічні засоби АСУ мають бути розміщені з дотриманням вимог, що містяться в технічній, у тому числі експлуатаційній, документації на них, і так, щоб було зручно використовувати їх при функціонуванні АСУ та виконувати технічне обслуговування.

1.4.5. Розміщення технічних засобів, що використовуються персоналом АСУ при виконанні автоматизованих функцій, повинно відповідати вимогам ергономіки: для виробничого обладнання за ГОСТ 12.049-80, для засобів подання зорової інформації за ГОСТ 21829-76, у тому числі для табло колективного користування з цифрових знакосинтезованих електролю. ГОСТ 21837-76.

1.4.6. Технічні засоби АСУ, що використовуються при взаємодії АСУ з іншими системами, повинні бути сумісні за інтерфейсами з відповідними технічними засобами цих систем та систем зв'язку.

1.4.7. В АСУ мають бути використані технічні засоби з терміном служби щонайменше десять років. Застосування технічних засобів з меншим терміном служби допускається лише в обґрунтованих випадках та за погодженням із замовником АСУ.

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

1.4.9. Технічні засоби АСУ допускається використовувати лише за умов, визначених в експлуатаційній документації на них. У випадках, коли необхідне їх використання в середовищі, параметри якого перевищують допустимі значення, встановлені для цих технічних засобів, повинні бути передбачені заходи захисту окремих технічних засобів АСУ від впливу факторів, що впливають.

1.4.10. В АСУ мають бути використані засоби обчислювальної техніки, що задовольняють загальні технічні вимоги за ГОСТ 22552-84.

1.4.11. В АСУ мають бути використані технічні засоби, що відповідають:

• по стійкості до зовнішніх факторів, що впливають - ГОСТ 12997-76 для промислових приладів та засобів автоматизації ГСП, ГОСТ 14254-80 для оболонок виробів електротехніки, ГОСТ 17516-72 для виробів електротехніки в частині впливу механічних факторів зовнішнього середовища, ГОСТ 21552-84 техніки;
• за параметрами живлення – ГОСТ 12997-76 для промислових приладів та засобів автоматизації ГСП, ГОСТ 21552-84 для засобів обчислювальної техніки;
• за категорією виконання - ГОСТ 12997-76 для промислових приладів та засобів автоматизації ДСП, ГОСТ 21552-84 для засобів обчислювальної техніки.

1.4.12. Захист технічних засобів АСУ від впливу зовнішніх електричних та магнітних полів, а також перешкод по ланцюгах живлення повинен бути достатнім для ефективного виконання технічними засобами свого призначення під час функціонування АСУ.

1.4.13. В АСУ відповідно до вимог, передбачених «Загальносоюзними нормами індустріальних перешкод, що допускаються» 1-72 - 9-72 та ГОСТ 23450-79, повинні бути передбачені заходи щодо захисту зовнішнього середовища від індустріальних радіоперешкод, випромінюваних технічними засобами АСУ при роботі, а також у момент включення та вимикання.

1.4.14. Загальні ергономічні вимоги до мнемосхем - за ГОСТ 21480-76, до рахункових пристроїв індикаторів візуальних - по ГОСТ 22902-78, до табло колективного користування на цифрових знакосинтезуючих електролюмінесцентних індикаторах - за ГОСТ 21837-76, до труб за ГОСТ 23144-78.

1.4.15. Загальні ергономічні вимоги до вимикачів на пультах: поворотним – за ГОСТ 22613-77, клавішним та кнопковим – за ГОСТ 22614-77, типу «Тумблер» – за ГОСТ 22615-77.

1.4.16. Загальні ергономічні вимоги до сигналізаторів первинних звукових повідомлень - за ГОСТ 21786-76.

1.4.17. Загальні ергономічні вимоги, що регламентують організацію робочого місця, взаємне розташування засобів відображення інформації, органів управління та зв'язку в межах робочого місця - за ГОСТ 22269-76, у тому числі пультів - за ГОСТ 23000-76.

1.4.18. Загальні ергономічні вимоги до крісел операторів згідно з ГОСТ 21889-76.

1.4.19. Загальні ергономічні вимоги до зали, кабін операторів та взаємного розташування місць - за ГОСТ 21958-76.

1.5. Вимоги до програмного забезпечення АСУ

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

1.5.2. Програмне забезпечення АСУ має мати такі властивості:

• функціональна достатність (повнота);
• надійність (у тому числі поновлюваність, наявність засобів виявлення помилок);
• адаптованість;
• модифікованість;
• модульність побудови та
• зручність експлуатації.

1.5.3. Програмне забезпечення АСУ має бути переважно побудовано на базі існуючих пакетів прикладних програм та інших програм, запозичених з державних, галузевих та інших фондів алгоритмів та програм, допускати завантаження та перевірку частинами та дозволяти проводити заміну одних програм без корекції інших.

1.5.4. В АСУ мають бути переважно використані системи управління базами даних (СУБД), зареєстровані в установленому порядку.

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

1.5.6. Програмне забезпечення АСУ повинно мати засоби діагностики технічних засобів АСУ та контролю за достовірністю вхідної інформації.

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

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

1.5.9. Усі програми спеціального програмного забезпечення конкретної АСУ мають бути сумісні як між собою, і з її загальним програмним забезпеченням.

1.5.10. Експлуатаційна програмна документація на АСУ повинна відповідати стандартам ЄСПД та містити всі відомості, необхідні персоналу АСУ для використання програмного забезпечення, для його початкового завантаження та (або) генерації, завантаження інформації внутрішньомашинної інформаційної бази, запуску програм АСУ, перевірки їх функціонування за допомогою відповідних тестів.

1.5.11. Програмні вироби, що знову розробляються при створенні конкретної АСУ, включені до складу її програмного забезпечення, повинні бути зареєстровані в державному, галузевому або інших фондах алгоритмів і програм (за належністю).

1.6. Вимоги до інформаційного забезпечення АСУ

1.6.1. Інформаційне забезпечення АСУ має бути достатнім до виконання всіх автоматизованих функцій АСУ.

1.6.2. Для кодування інформації, яка використовується тільки в цій АСУ, повинні бути застосовані класифікатори, прийняті у замовника АСУ.

1.6.3. Для кодування в АСУ вихідної інформації, яка використовується на вищому рівні, повинні бути застосовані класифікатори вищих систем управління, крім спеціально обумовлених випадків.

1.6.4. Загальні ергономічні вимоги до кодування інформації – за ГОСТ 21829-76.

1.6.5. В АСУ для зв'язку між пристроями комплексу технічних засобів мають бути застосовані:

• вхідні та вихідні сигнали:
  • електричні - струму та напруги за ГОСТ 26.011-80, з дискретною зміною параметрів за ГОСТ 26.013-81, кодовані за ГОСТ 26.014-81,
  • гідравлічні за ГОСТ 26.012-80,
  • пневматичні за ГОСТ 26.015-81;
• набори алфавітно-цифрових символів за ГОСТ 19767-74;
• коди 8-бітові за ГОСТ 19768-74.

1.6.6. Інформаційне забезпечення АСУ має бути сумісне з інформаційним забезпеченням систем, що взаємодіють з нею, за змістом, системою кодування, методами адресування, форматами даних та формою подання інформації, що отримується та видається АСУ.

1.6.7. Форми документів, що створюються АСУ, мають відповідати вимогам стандартів УСД чи нормативно-технічних документів відомства замовника АСУ.

1.6.8. Форми документів та відеокадрів, що вводяться, виводяться або коригуються через термінали АСУ, повинні бути узгоджені з відповідними технічними характеристиками терміналів.

1.6.9. Сукупність інформаційних масивів АСУ має бути організована як баз даних на машинних носіях.

1.6.10. Форма подання вихідної інформації АСУ має бути узгоджена із замовником (користувачем) системи.

1.6.11. Терміни та скорочення, що застосовуються у вихідних документах АСУ, повинні бути загальноприйнятими в даній предметній галузі та узгоджені із замовником системи.

1.6.12. В АСУ мають бути передбачені необхідні заходи щодо контролю та оновлення даних в інформаційних масивах АСУ, відновлення масивів після відмови будь-яких технічних засобів АСУ, а також контролю ідентичності однойменної інформації у базах даних.

1.7. Вимоги до організаційного забезпечення АСУ

1.7.1. Організаційне забезпечення АСУ має бути достатнім для ефективного виконання персоналом АСУ покладених на нього обов'язків при здійсненні автоматизованих на нього обов'язків при здійсненні автоматизованих та пов'язаних із ними неавтоматизованих функцій системи.

1.7.2. Організаційна структура АСУ має дозволяти виконувати всі функції АСУ з урахуванням їхнього розподілу за рівнями управління.

1.7.3. Вимоги до розподілу обов'язків серед персоналу, який бере участь у функціонуванні АСУ в режимі реального часу, визначають з урахуванням вимог 11 обов'язкового додатка 1.

1.7.4. Інструкції організаційного забезпечення АСУ повинні визначати дії персоналу АСУ, необхідні для виконання кожної автоматизованої функції, у всіх режимах функціонування АСУ, з урахуванням заданих вимог щодо безпомилковості та швидкодії реалізації персоналом АСУ своїх функціональних обов'язків, а також містити конкретні вказівки про дії у разі виникнення аварійних ситуацій чи порушення нормальних умов функціонування АСУ. Вимоги до змісту інструкцій – за ГОСТ 24.209-80.

1.7.5. За кожною автоматизованою функцією, яка виконується у взаємодії даної АСУ з іншими системами, інструкції персоналу АСУ та цих систем повинні бути взаємопов'язані для всіх режимів виконання даної функції та містити вказівки про дії персоналу за відмов технічних засобів АСУ.

1.8. Вимоги до лінгвістичного забезпечення АСУ

1.8.1. Лінгвістичне забезпечення АСУ має бути достатнім для спілкування різних категорій користувачів у зручній для них формі із засобами автоматизації АСУ та для здійснення процедур перетворення та машинного подання оброблюваної в АСУ інформації.

1.8.2. У лінгвістичному забезпеченні АСУ мають бути:

• передбачені мовні засоби для опису будь-якої інформації, що використовується в АСУ;
• уніфіковано використовувані мовні засоби;
• стандартизовані описи однотипних елементів інформації та запису синтаксичних конструкцій;
• забезпечені зручність, однозначність та стійкість спілкування користувачів із засобами автоматизації АСУ;
• передбачені засоби виправлення помилок, що виникають під час спілкування користувачів з технічними засобами АСУ.

1.8.3. Лінгвістичне забезпечення АСУ має бути відображено у документації (інструкціях, описах) організаційного забезпечення АСУ у вигляді правил спілкування користувачів з технічними засобами АСУ у всіх режимах функціонування системи.

1.9. Вимоги до правового забезпечення АСУ

Правове забезпечення АСУ має включати сукупність правових норм:

• визначальних юридичну силу інформації на носіях даних та документів, що використовуються при функціонуванні АСУ та створюваних системою;
• що регламентують правовідносини між людьми, що входять до складу персоналу АСУ (права, обов'язки та відповідальність), а також між персоналом АСУ та персоналом систем, що взаємодіють з АСУ.

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

1.10. Вимоги до експлуатаційної документації на АСУ

1.10.1. Експлуатаційна документація на АСУ має бути достатньою для введення АСУ у дію та її ефективного функціонування.

1.10.2. Експлуатаційна документація на АСУ має:

• містити відомості, необхідні для швидкого та якісного освоєння та правильної експлуатації засобів автоматизації АСУ;
• містити вказівки щодо діяльності персоналу АСУ в аварійних ситуаціях або за порушення нормальних умов функціонування АСУ;
• не містити положень, що допускають неоднозначне тлумачення.

2. ВИМОГИ БЕЗПЕКИ

2.1. Неправильні дії персоналу АСУ не повинні спричиняти аварійну ситуацію.

2.2. Вимоги щодо безпеки електротехнічних виробів, що використовуються в АСУ, - за ГОСТ 12.2.007.0-75.

2.3. Вимоги щодо безпеки засобів обчислювальної техніки, що використовуються в АСУ, - за ГОСТ 25861-83.

2.4. Усі зовнішні елементи технічних засобів АСУ, що перебувають під напругою, повинні мати захист від випадкового дотику, а самі технічні засоби мати занулення або захисне заземлення відповідно до ГОСТ 12.1.030-81 та «Правила пристрою живлення».

2.5. Технічні засоби АСУ, що розміщуються на вибухо- та пожежонебезпечних установках, повинні відповідати вимогам «Правил пристрою живлення».

2.6. Технічні засоби АСУ мають бути встановлені так, щоб забезпечувалася їх безпечна експлуатація та технічне обслуговування.

2.7. Вимоги безпеки повинні бути встановлені спеціальним розділом посадових інструкцій та (або) інструкції з експлуатації АСУ та посилання на інструкції з експлуатації технічних засобів.

2.8. Загальні ергономічні вимоги до робочих місць персоналу АСУ – за ГОСТ 22269-76.

2.9. Комфортні умови проживання персоналу АСУ повинні відповідати діючим санітарним нормам, гранично допустимі умови заселеності - за ГОСТ 12.1.005-76, допустимі рівні впливу небезпечних та шкідливих виробничих факторів - за ГОСТ 12.0.003-74.

2.10. Загальні ергономічні вимоги до мікроклімату робочих приміщень персоналу АСУ – за ГОСТ 12.1.005-76.

2.11. Рівні шуму та звукової потужності у місцях розташування персоналу АСУ не повинні перевищувати значень, встановлених ГОСТ 12.1.003-83 та санітарним нормам, при цьому мають бути враховані рівні шумів та звукової потужності, що створюються всіма джерелами, у тому числі і акустичними засобами передачі даних.

2.12. Рівні освітленості робочих місць персоналу АСУ мають відповідати характеру та умовам праці. Повинні бути передбачені захист від сліпучої дії світла та усунення відблисків.

2.13. Загальні ергономічні вимоги до вібрації обладнання на робочих місцях персоналу АСУ – за ГОСТ 12.1.012-78.

2.14. Сигнальні кольори та знаки безпеки за ГОСТ 12.4.026-76.

3. ВИДИ І ПОРЯДОК ПРОВЕДЕННЯ ВИПРОБУВАНЬ ПРИ ВВЕДЕННІ АСУ У ДІЮ

Цей розділ поширюється на всі АСУ, крім створюваних на замовлення Міністерства оборони.

3.1. АСУ або окрема функція АСУ (далі - АСУ) при введенні її в дію повинна пройти попередні та приймальні випробування, а також випробування, передбачені нормативно-технічними документами, що діють у відомстві замовника АСУ.

3.2. Приймальних випробувань АСУ має передувати її дослідна експлуатація на об'єкті управління.

3.3. Випробування АСУ проводять відповідно до документа «Програма випробувань», який готує розробник АСУ. Вимоги до змісту програми випробувань – за ГОСТ 24.208-80.

3.4. Випробування АСУ допускається проводити за один чи кілька етапів.

За результатами випробувань АСУ складають "Протокол випробувань". Вимоги до змісту протоколу випробувань – за ГОСТ 24.208-80.

При поетапному випробуванні АСУ у «Протоколі випробувань» за результатами попереднього етапу має бути висновок щодо можливості подання АСУ на наступний етап випробувань.

3.5. Попередні випробування АСУ

3.5.1. Попередні випробування АСУ проводять визначення її працездатності та вирішення питання про можливість приймання АСУ в дослідну експлуатацію.

3.5.2. "Програму випробувань" для попередніх випробувань АСУ затверджує замовник АСУ.

3.5.3. Попередні випробування АСУ організує замовник та проводять розробник АСУ та замовник спільно.

3.5.4. Комісію щодо попередніх випробувань АСУ утворюють наказом замовника. Головою комісії призначають представника замовника АСУ.

3.5.6. У «Протоколі випробувань», складеному за результатами попередніх випробувань АСУ, наводять висновок про можливість приймання АСУ в дослідну експлуатацію, а також перелік необхідних доопрацювань та терміни їх виконання, що рекомендуються.

3.6. Досвідчена експлуатація АСУ

3.6.1. Результати приймання АСУ у дослідну експлуатацію оформляють «Актом приймання в дослідну експлуатацію», складеним на підставі «Протоколу випробувань» комісією, яка проводила попередні випробування АСУ. Вимоги до змісту акта – за ГОСТ 24.208-80.

3.6.2. Тривалість дослідної експлуатації АСУ визначають за термінами, необхідні для перевірки правильності функціонування АСУ при виконанні кожної автоматизованої функції та готовності персоналу АСУ до участі у виконанні всіх автоматизованих функцій АСУ.

3.6.3. Мінімальну тривалість дослідної експлуатації АСУ (крім ОАСУ) перед приймальними випробуваннями визначають для кожної автоматизованої функції АСУ, що здається, вона повинна відповідати значенням, зазначеним у таблиці. Якщо загальна тривалість порушень безперервності виконання автоматизованої функції перевищує значення, зазначене в таблиці, дослідна експлуатація має бути продовжена до отримання результатів, що відповідають таблиці, або до ухвалення рішення про її припинення.

Допускається за погодженням із замовником подавати АСУ на приймальні випробування без досвідченої експлуатації тих її автоматизованих функцій, частота вирішення яких рідше одного разу на місяць, за умови, що в АСУ автоматизовано не лише такі функції.

Частота виконання автоматизованої функції	Мінімальна тривалість дослідної експлуатації АСУ перед приймальними випробуваннями	Допустима загальна тривалість порушень безперервності виконання автоматизованої функції АСУ
Безперервно	1 міс	Не більше 3 діб
Один раз на добу та частіше	Те саме	Не більше 10% планової кількості рішень
Рідше ніж один раз на добу до одного разу на місяць	3 міс	Те саме
Рідше одного разу на місяць до одного разу на півроку	Період між двома послідовними рішеннями	Порушення безперервності виконання функції не допускаються
Раз на рік і рідше	Період часу, необхідний для перевірки прийнятої технології збору та переробки інформації у процесі одноразового виконання функції АСУ	Те саме

Примітки:

1. Порушенням безперервності виконання автоматизованої функції АСУ вважають її невиконання у передбачений технічною документацією на АСУ момент часу, якщо це не спричинено порушенням умов функціонування АСУ або об'єкта управління.

2. Якщо фактична тривалість дослідної експлуатації АСУ була більшою за час, зазначений у другій графі таблиці, то загальну тривалість порушення безперервності виконання для кожної автоматизованої функції визначають за період часу, зазначений у таблиці та безпосередньо передує приймальним випробуванням.

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

3.6.5. За результатами дослідної експлуатації складають акт про завершення робіт із перевірки АСУ у режимі дослідної експлуатації. Вимоги до змісту акта – за ГОСТ 24.208-80.

3.7. Приймальні випробування АСУ

3.7.1. Приймальні випробування АСУ проводять визначення її відповідності ТЗ на АСУ, вимогам цього стандарту та визначення можливості введення АСУ в дію.

3.7.2. Залежно від важливості об'єкта управління та АСУ приймальні випробування можуть бути:

• державні;
• міжвідомчі;
• відомчі

та мають бути проведені відповідними приймальними комісіями. Приймальну комісію утворюють наказом міністерства (відомства) замовника АСУ. Рівень приймальної комісії має бути встановлений у ТЗ на АСУ.

3.7.3. Головою приймальної комісії призначають представника замовника АСУ. До складу приймальної комісії обов'язково включають представників розробника АСУ.

3.7.4. Робота приймальної комісії не включає приймання будівель, споруд та допоміжного обладнання, створення яких здійснено у зв'язку із створенням АСУ. Комісія перевіряє лише наявність актів про приймання їх в експлуатацію та виконання вимог, що містяться у завданнях на проектування у суміжних частинах проекту об'єкта, виданих у ході проектування АСУ.

3.7.5. Приймальній комісії замовник та розробник пред'являють таку документацію:

• технічне завдання створення АСУ;
• проект програми приймальних випробувань;
• протокол попередніх випробувань АСУ;
• акт приймання АСУ у дослідну експлуатацію;
• акт (акти) про завершення робіт з перевірки АСУ у режимі дослідної експлуатації;
• технічну документацію на АСУ (за рішенням приймальної комісії).

3.7.6. Перед пред'явленням на приймальні випробування АСУ, що має вимірювальні канали, проводять їх метрологічну атестацію відповідно до чинних стандартів.

3.7.7. Перед поданням АСУ на приймальні випробування система та її технічна документація мають бути доопрацьовані за зауваженнями протоколу попередніх випробувань та акта про завершення робіт з перевірки АСУ у режимі дослідної експлуатації.

Допускається за рішенням приймальної комісії доопрацювання технічної документації АСУ після її введення в дію. Терміни доопрацювання технічної документації АСУ вказують у протоколі приймальних випробувань системи.

3.7.8. Приймальні випробування АСУ мають бути проведені на об'єкті управління, що функціонує.

3.7.9. «Програма випробувань» для приймальних випробувань АСУ має бути затверджена рішенням приймальної комісії. Узгодження програми приймальних випробувань із замовником АСУ є обов'язковим.

3.7.10. За результатами приймальних випробувань комісія складає протокол випробувань та акт про введення АСУ в дію (або висновок про неприйняття АСУ з переліком необхідних доопрацювань та термінами їх виконання, що рекомендуються). Вимоги до змісту протоколу та акта за ГОСТ 24.208-80. Вимоги до змісту висновку про неприйняття АСУ аналогічні вимогам щодо змісту акта про введення АСУ у дію.

3.7.11. У разі поетапного проведення приймальних випробувань акт про введення АСУ у дію оформляють на підставі актів про введення в дію окремих частин системи та (або) «Протоколів випробувань» усіх етапів приймальних випробувань АСУ.

3.7.12. Датою введення АСУ у дію вважають дату підписання акта про введення в дію приймальною комісією.

3.7.13. Акт про введення АСУ у дію затверджує міністерство (відомство) замовника.

4. КОМПЛЕКТНІСТЬ АСУ, ВВЕДЕНОЇ В ДІЮ

4.1. В АСУ повинні входити:

• технічні засоби АСУ як комплексу технічних засобів АСУ, підготовленого до експлуатації;
• запасні вироби та прилади (ЗІП), прилади та пристрої для перевірки працездатності, налагодження технічних засобів та контролю метрологічних характеристик вимірювальних каналів АСУ в обсязі, передбаченому замовною проектною документацією, погодженою із замовником АСУ та службою метрології користувача в частині апаратури перевірки;
• експлуатаційною документацією за ГОСТ 2.601-68 на кожен із виробів, що входять до складу КТС АСУ;
• не менше двох екземплярів програм на носіях даних та експлуатаційної документації на них за ГОСТ 19.101-77, з урахуванням обмежень та доповнень за ГОСТ 24.101-80 та ГОСТ 24.207-80;
• формуляр на програмне забезпечення АСУ в цілому або на програмне забезпечення функції АСУ, що вводиться в дію окремо і формуляри на програмні вироби (ГОСТ 19.004-80), кожен в одному примірнику. Вимоги до формуляра - за ГОСТ 19.501-78;
• два екземпляри експлуатаційної документації на АСУ за ГОСТ 24.101-80, у тому числі необхідна документація інформаційного забезпечення АСУ (формуляр АСУ в одному примірнику).

За погодженням між розробником АСУ та замовником АСУ комплектність АСУ може бути розширена.

4.2. Штати АСУ мають бути укомплектовані персоналом, який відповідає вимогам п. 1.3.

4.3. Для комплектації створюваної АСУ можуть бути використані такі, що постачаються як продукція виробничо-технічного призначення:

• комплекс (комплекси) технічних та програмних засобів з експлуатаційною документацією на них за ГОСТ 2.601-68;
• програмні вироби з експлуатаційною документацією на них за ГОСТ 19.101-77;
• технічні засоби з експлуатаційною документацією на них згідно з ГОСТ 2.601-68.

4.4. Порядок розробки, постановки на виробництво та випробувань комплектуючих, що постачаються в АСУ, повинен відповідати Державним стандартам системи розробки та постановки продукції на виробництво.

Перед постановкою виробництва дослідні зразки комплектуючих піддають приймальним (державним, міжвідомчим, відомчим) випробуванням.

5. ГАРАНТІЇ

5.1. Розробник АСУ гарантує відповідність АСУ вимогам цього стандарту та ТЗ на АСУ при дотриманні користувачем умов та правил експлуатації.

5.2. відповідність технічних, програмних засобів і комплексів засобів автоматизації вимогам стандартів і ТУ, що застосовуються в АСУ і постачаються як продукція виробничо-технічного призначення, на них гарантують виробники цих видів продукції при дотриманні користувачем умов і правил експлуатації.

5.3. Гарантійний термін експлуатації на АСУ обчислюють із дня введення АСУ у дію.

5.4. Гарантійний термін експлуатації на АСУ має бути встановлений у ТЗ на АСУ і не може бути меншим за 18 міс.

ДОДАТОК 1
Обов'язкове

ДОДАТКОВІ ВИМОГИ ДО АВТОМАТИЗОВАНИХ СИСТЕМ УПРАВЛІННЯ ТЕХНОЛОГІЧНИМИ ПРОЦЕСАМИ (АСУ ТП)

1. АСУ ТП у промисловості та у непромисловій сфері має керувати технологічним об'єктом загалом та забезпечувати взаємопов'язані з нею системи достовірною технологічною та техніко-економічною інформацією про роботу технологічного об'єкта управління (ТОУ).

2. АСУ ТП повинна виробляти та реалізовувати раціональні за цілями та критеріями управління керуючі впливу на ТОУ у реальному масштабі часу протікання технологічного процесу в об'єкті управління.

3. АСУ ТП має виконувати керуючі, інформаційні та допоміжні функції.

4. АСУ ТП має бути сумісна з усіма взаємопов'язаними з нею автоматизованими системами (АС), зазначеними у ТЗ на АСУ ТП, у тому числі з системами, що входять разом із даною АСУ ТП до складу гнучкого автоматизованого виробництва, наприклад, САПР технології, автоматизованими складськими та транспортними системами, АС технологічної підготовки виробництва.

5. Керуючі впливи в АСУ ТП повинні вироблятися автоматично або формуватись її оперативним персоналом за допомогою комплексу засобів автоматизації, що входить до системи.

6. АСУ ТП має забезпечувати управління об'єктом у нормальних, перехідних та передаварійних умовах його функціонування, а також захист чи зупинку об'єкта при загрозі аварії.

7. АСУ ТП має здійснювати функцію контролю виконання керуючих впливів на ТОУ та сигналізувати про вихід виконавчих органів у гранично допустимі положення.

8. При реалізації функції аварійного автоматичного відхилення обладнання в АСУ ТП повинна бути забезпечена сигналізація про це оперативному персоналу за допомогою світлового та, за необхідності, звукового сигналу з автоматичною реєстрацією часу відключення.

9. Як основні технічні засоби АСУ ТП повинні бути використані вироби Державної системи промислових приладів та засобів автоматизації (ГСП), інші вироби, які відповідають вимогам стандартів ЄССП, та засоби обчислювальної техніки, що відповідають ГОСТ 21552-84.

10. Технічні засоби АСУ ТП, що розміщуються на технологічному обладнанні, повинні відповідати вимогам, що висуваються до них умов експлуатації.

11. Обов'язки між операторами мають бути розподілені з урахуванням:

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

12. Кожна особа, яка входить до складу персоналу, повинна мати:

• знаннями, обсяг та глибина яких дозволяє йому виконувати дії (взаємодії), що входять у відповідні автоматизовані та взаємопов'язані з ними неавтоматизовані функції АСУ ТП, а також приймати правильні рішення в аварійних ситуаціях або за інших порушень нормальної експлуатації;
• відпрацьованими навичками, що дозволяють із заданими безпомилковістю та швидкодією виконувати всі дії та взаємодії.

13. У програмному забезпеченні АСУ ТП мають бути передбачені, а в організаційному забезпеченні відображені мовні засоби для спілкування оперативного персоналу з КТС АСУ ТП, зручні та доступні для осіб, які не мають кваліфікації програміста.

14. Коди та умовні позначення, що використовуються в АСУ ТП, повинні бути наближені до термінів та понять, що застосовуються технологічним персоналом об'єкта управління, і не повинні викликати труднощів при їх сприйнятті.

15. Вимірювальні канали АСУ ТП повинні мати метрологічні характеристики, що забезпечують виконання її інформаційних функцій із показниками, заданими у ТЗ на АСУ ТП.

16. Вимоги до випробувань АСУ ТП

16.1. Попередні випробування АСУ ТП проводять на діючому ТОВ.

16.2. Попередні випробування функцій АСУ ТП, необхідні проведення пуску і обкатки технологічного устаткування, допускається проводити об'єкті з допомогою імітаторів.

16.3. Визначення фактичних значень показників техніко-економічної ефективності та надійності АСУ ТП здійснюють після її введення в дію. Тривалість напрацювання АСУ ТП, необхідну визначення фактичних значень її показників, розраховують за відповідними методиками, затвердженим у порядку.

ДОДАТОК 2
Обов'язкове

ДОДАТКОВІ ВИМОГИ ДО АСУ ПІДПРИЄМСТВАМИ, ВИРОБНИЧИМИ І НАУКОВО-ВИРОБНИЧИМИ ОБ'ЄДНАННЯМИ

1. АСУ має підвищувати ефективність виробничо-господарської діяльності підприємствами, виробничого чи науково-виробничого об'єднання (надалі - підприємства).

2. АСУ підприємством (АСУП) має забезпечувати автоматизований збір та обробку інформації з широким використанням методів оптимізації за основними завданнями та підсистемами управління загальнозаводського та цехового рівня, у тому числі за потреби у реальному масштабі часу в режимі телеобробки та діалогу.

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

4. Організаційне забезпечення АСУП має передбачати вдосконалення методів управління та структури системи управління підприємствами при створенні та розвитку АСУП.

ДОДАТОК 3
Обов'язкове

ДОДАТКОВІ ВИМОГИ ДО ГАЛУЗЕВИХ АВТОМАТИЗОВАНИХ СИСТЕМ УПРАВЛІННЯ (ОАСУ)

1. ОАСУ має забезпечувати:

• поліпшення характеристик об'єкта управління (підвищення продуктивності праці галузі, підвищення якості продукції, своєчасне виконання поставок продукції, зниження собівартості своєї продукції);
• вдосконалення процесів обробки інформації (зниження вартості обробки інформації, підвищення достовірності вихідних, підвищення точності та оперативності розрахунків);
• вдосконалення організації виконання функцій управління (зокрема, раціональний розподіл робіт між підрозділами апарату управління, обчислювальними центрами та науково-дослідними організаціями та підприємствами).

2. В ОАСУ мають бути автоматизовані функції управління галуззю, наприклад:

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

3. ОАСУ має бути реалізована у вигляді сукупності спільно функціонуючих підсистем, взаємодія між якими має відбуватися через загальні бази даних.

4. ОАСУ повинна включати систему збору даних, що базується на обчислювальних центрах ОАСУ, організацій та підприємств галузі, що забезпечує раціональний розподіл у базах даних інформації для вирішення взаємодіючих завдань та передачу інформації між системами каналів зв'язку та на машинних носіях.

5. ОАСУ має забезпечувати інтерактивний режим роботи з базами даних системи.

6. Створення ОАСУ має призводити до вдосконалення методів та структури управління галуззю.

7. Тривалість дослідної експлуатації частин ОАСУ повинна забезпечувати одноразове проведення всіх розрахунків, необхідних для виконання автоматизованих функцій частини ОАСУ, що вводиться, і не повинна перевищувати 3 міс.

Конкретну тривалість дослідної експлуатації ОАСУ встановлюють за узгодженням між розробником та замовником.

ДОДАТОК 4
Довідкове

ПОЯСНЕННЯ ДО ДЕЯКИХ ТЕРМІН, ЩО ВИКОРИСТОВУЮТЬСЯ У СЬОГОДНІМ СТАНДАРТІ

Комплекс засобів автоматизації (КСА)- сукупність взаємоузгоджених комплексів технічних і програмних засобів (виробів), що поставляється, розроблена і виготовлена ​​як продукція виробничо-технічного призначення. До складу КСА можуть включатися інші вироби та (або) документи, що входять до інформаційного, організаційного або інших видів забезпечення автоматизованих систем.

Нарощування АСУ- Сукупність заходів, що вживаються в АСУ при розширенні її об'єкта управління без зміни складу функцій АСУ.

Відеокадр (в АСУ)- Зображення на екрані електронно-променевої трубки документа малюнка або тексту повідомлення, що використовуються в АСУ.

Вимірювальний канал АСУ- функціонально об'єднана сукупність технічних та (за потреби) програмних засобів, призначена для реалізації однієї простої вимірювальної функції АСУ.

Попередні випробування АСУ- Контрольні випробування, що проводяться з метою визначення можливості приймання АСУ в дослідну експлуатацію.

Приймальні випробування АСУ- контрольні випробування АСУ, що проводяться для визначення відповідності технічному завданню на створення АСУ, вимогам стандартів та визначення можливості введення АСУ в дію.

Державні випробування- приймальні випробування АСУ, які проводяться державною комісією.

Міжвідомчі випробування- приймальні випробування АСУ, що проводяться комісією із представників кількох зацікавлених міністерств та (або) відомств.

Відомчі випробування- приймальні випробування АСУ, які проводяться комісією із представників зацікавленого міністерства чи відомства.

Редактор О.І. Ломіна
Технічний редактор Н.П. Замолодчикова
Коректор Є.І. Євтєєва
Здано до набору 16.01.86. Підписано до друку 08.04.86. Ум. піч. л. 1,5. Ум. кр.-отд. 1,5 Уч.-вид. л. 1,5.
Тираж 40000 Ціна 10 коп.
Ордена «Знак Пошани» Видавництво стандартів, 123810, Москва, ДСП, Новопресненський пров., 3
Тип. "Московський друкар", Москва, Лялін пров., 6. Замовлення 1772

Сьогодні ми поговоримо про вітчизняні стандарти на проектну документацію. Як ці стандарти працюють на практиці, чим вони погані та чим хороші. При розробці документації для державних та серйозних приватних замовників у нас зазвичай немає вибору – до вимог з документування ТЗ вписано дотримання стандартів. На практиці мені доводилося стикатися з різними прикладами нерозуміння структури стандартів, того, що має бути в документах і навіщо ці документи потрібні. У результаті з-під пера техписьменів, аналітиків та фахівців виходять часом такі перли, що незрозуміло, в якому стані свідомості вони писалися. Адже насправді все досить просто. Пошук по Хабру не повернув посилань на більш-менш цілісний матеріал на цю тему, тому пропоную зафарбувати цю прикру прогалину.

Що таке стандарти документації?

У серії 34, про яку йдеться, існує всього 3 основні стандарти з документування:

Найулюбленіший і найпопулярніший стандарт із розробки ТЗ. Єдине, не варто забувати, що він міцно пов'язаний з іншими стандартами серії і якщо ви отримали ТЗ, виконане за цим стандартом, дуже бажано дотримуватися інших стандартів, навіть якщо про це немає прямих вимог. Хоча б у плані загальної ідеології (про яку нижче)

Це базовий документ, в якому наводиться повний перелік документації ГОСТ 34, рекомендації щодо кодування документів, до яких стадій проекту відносяться документи (стадії описуються в ГОСТ 34601-90), а також як їх можна об'єднати між собою.

Фактично, цей стандарт є великою таблицею з коментарями. Її можна загнати до Excel для зручності використання.

Об'ємний стандарт, що з різним ступенем детальності описує зміст проектних документів. Як індекс використовується згаданий вище ГОСТ 34.201-89.

До стандарту РД 50-34.698-90 існує безліч питань і трактувань його положень, які через їх неконкретність часто розуміють по-різному замовник і виконавець або навіть члени проектної команди. Але нічого конкретнішого в нас, на жаль, немає.

Розглянемо тепер плюси та мінуси стандартів, розпочавши традиційно з мінусів.

Мінуси стандартів

Основний мінус усім очевидний – стандарти старі. Вони закладено застаріле уявлення про архітектуру автоматизованої системи. Наприклад:

• додатки дворівневі, що складаються з клієнтської програми та сервера СУБД (ніяких трьох- і більш «рівневих» додатків, жодних Weblogic або JBoss)
• структура таблиць бази даних, будучи описана, дасть уявлення про логічну модель даних (те, що між додатком і базою може бути якийсь Hibernate, тоді здавалося поганою надмірністю)
• користувальницький інтерфейс одновіконний (а хіба буває інший? А що таке "браузер"?)
• Звітів у системі небагато, всі вони паперові та друкуються на матричному принтері
• Програма, що розробляється, орієнтована на рішення «завдання обробки інформації», яка має чіткий вхід і вихід і вузько спеціалізована. В основі обробки інформації лежить "алгоритм". Іноді "алгоритмів" буває кілька. (Об'єктно-орієнтоване програмування тоді робило лише свої перші кроки і не розглядалося).
• адміністратор бази даних розуміє, яка інформація лежить у таблицях і бере активну участь у редагуванні системних довідників (а хіба буває один сервер СУБД для 50 різних додатків?)

Відповідно, у стандарті є артефакти, на кшталт наступного:

5.8. Креслення форми документа (відеокадра)
У документі має бути наведено зображення форми документа або відеокадра відповідно до вимог державних стандартів уніфікованої системи документації Р 50-77 та необхідні пояснення.

Сенс документа в тому, що на радянських підприємствах використовувалися так звані «Дільниці друку», де стояли матричні швидкісні принтери, драйвери яких часто писали самі інженери. Тому вони повинні були підтримувати реєстр усіх документів, які потрібно друкувати для гарантії того, що в надрукованому вигляді документи виглядатимуть так, як належить.

"Відеокадр" - це теж документ, який виводився на текстовий дисплей. Дисплеї не завжди підтримували потрібні символи та потрібну кількість символів по горизонталі та рядків по вертикалі (а графіку взагалі не підтримували). Тому тут також треба було додатково узгоджувати форми всіх екранних документів.

Нині вже нам нічого не кажуть слова "машинограма", "відеокадр", "АЦПУ". Я теж їх не застав у вживанні, хоча закінчував профільний інститут у 90-ті. Це був час появи Windows 3.1, VGA дисплеїв, тридюймових дискет та перших вітчизняних інтернет-сайтів. Але в стандарті ці слова є, і замовник іноді примхливо вимагає надати йому повний комплект документації відповідно до ГОСТ 34.201-89. Більше того, подібні формулювання в ТЗ кочують з одного міністерства до іншого і стали вже якимось негласним шаблоном, який вбивають змістовну частину.

Тож документ із безглуздою назвою «Креслення форми документа (відеокадра)» у проекті має бути і має бути не порожнім.

Що у стандарті добре

Будь-який стандарт хороший вже тим, що він дозволяє замовнику і виконавцю говорити однією мовою і дає гарантію, що принаймні претензій «за формою» до результатів, що передаються, у замовника не буде.

А стандарти ГОСТ 34 хороші ще й тим, що вони складалися розумними людьми, обкочувалися роками і мають чітку мету - максимально повно описати на папері складну абстрактну сутність, яку являє собою будь-яка АСУ.

Коли вам потрібно грамотно поставити завдання західним підрядникам, які про наші ГОСТи не чули, можна також спиратися на ці стандарти, а точніше на їх контент, смислову складову. Тому що, повторюся, гарантія повноти інформації дорогого коштує. Як би ми себе не тішили високим рівнем свого професіоналізму, ми можемо забути включити до наших вимог елементарні речі, тоді як той же ГОСТ 34.602-89 «пам'ятає» про все. Якщо вам незрозуміло, як має виглядати результат роботи західних підрядників, подивіться на вимоги до документування, рекомендованих розділів. Запевняю вас, краще не вигадати! Швидше за все, є західні аналоги наших стандартів, у яких все може бути повнішим, сучаснішим і кращим. На жаль, я з ними не знайомий, тому що не було поки жодного випадку, щоб наших ГОСТів було б недостатньо.

Можна сміятися з того, що творці стандартів нічого не знали про java чи .NET, про HD монітори та Інтернет, але я б не радив недооцінювати масштаб виконаної ними роботи та її цінність для нашої професійної спільноти.

Як читати та розуміти стандарти документації по ГОСТ серії 34

Стандарт поділяє всі документи по двох осях - час та предметна область. Якщо подивитися таблицю 2 у ГОСТ 34.201-89, то добре видно цей поділ (колонки «Стадія створення» та «Частина проекту»

Стадії створення АСУ

Стадії створення визначені у ГОСТ 34.601-90. Мають відношення до документування з них три:

• Ескізний проект (ЕП)
• Технічний проект (ТП)
• Розробка робочої документації (РД)

Ескізний проектслід після стадії Технічне завдання і служить розробки попередніх проектних рішень.

Технічний проектописує майбутню систему з усіх ракурсів. Документи стадії ТП повинні після прочитання залишати після себе повну ясність у пропонованих підходах, методах, архітектурних та технічних рішеннях. На наступній фазі вже пізно буде описувати підходи та обґрунтовувати технічні рішення, так що фаза П є ключем до успішної здачі робіт, оскільки все різноманіття вимог ТЗ має знаходити відображення у документах фази П. На етапі П система може взагалі не існувати.

Робоча документаціяпризначена для успішного розгортання, введення в дію та подальшої експлуатації нової системи. Це документи, що містять конкретні відомості, що описують фізично існуючі сутності, на відміну від фази П, де описується майбутнє пишнота.

Частини (розділи) проектної документації щодо створення АСУ

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

Автоматизована система в поданні упорядників ГОСТ являє собою сукупність заліза, софту і каналів зв'язку, яка обробляє інформацію, що надходить з різних джерел, відповідно до деяких алгоритмів і видає результати обробки у вигляді документів, структур даних або керуючих впливів. Примітивна модель найпростішого автомата.

Щоб повністю описати цей «автомат», зроблено такі розрізи (як у кресленні):

Математичне забезпечення (МО), що відповідає питанням: яка логіка зашита всередині «чорного ящика»? Чому вибрано саме ці алгоритми, саме такі формули та саме такі коефіцієнти?

Математичне забезпечення нічого не знає ні про процесори, ні про бази даних. Це окрема абстрактна область, обитель "сферичних коней у вакуумі". Але математичне забезпечення буває дуже щільно пов'язане з предметною областю, як реальне життя. Наприклад, керуючі алгоритми для систем управління дорожнім рухом потрібно узгодити в ДІБДР перед тим, як їх узгоджуватиме замовник. І тут розумієш, навіщо їх виділяють в окрему книжечку. Тому що в ДІБДР нікому не цікаво, на якій ОС працюватиме сервер програми, а ось який знак і обмеження швидкості вискочить на табло в дощ або сніг дуже цікаво. Вони відповідають за свою частину і нічого іншого підписувати не збираються. З іншого боку, коли вони підписали, не буде питань до технічної сторони питання – чому вибрали ті, а не інші табло чи світлофори. Мудрість «предків» якраз і виявляється в таких практичних кейсах.

Інформаційне забезпечення (ІВ). Ще один зріз системи. На цей раз робиться прозорим чорний ящик нашої системи і ми дивимося на інформацію, що циркулює в ньому. Уявіть собі модель кровоносної системи людини, коли інші органи невидимі. Ось щось подібне і є інформаційним забезпеченням. У ньому описуються склад і маршрути проходження інформації всередині та зовні, логічна організація інформації в системі, опис довідників та систем кодування (хто робив програми для виробництва, той знає, наскільки вони важливі). Основна описова частина посідає етап ТП, але на етап РД перетікають деякі «рудименти», на кшталт документа «Каталог баз даних». Зрозуміло, що раніше він містив те, що написано в назві. Але сьогодні спробуйте для складної комплексної системи сформувати такий документ, коли часто-густо у складі системи використовуються покупні підсистеми зі своїми загадковими інформаційними сховищами. Я вже не говорю про те, що цей документ не особливо зараз і потрібен.

Або ось «Відомість машинних носіїв інформації». Зрозуміло, що раніше у ньому були номери магнітних барабанів чи бобін із плівкою. А зараз що туди вносити?

Коротше, на фазі РД документи Інформаційного забезпечення є досить шкідливим рудиментом, оскільки формально вони повинні бути, але наповнювати їх особливо нічим.

Програмне забезпечення (ПЗ). Улюблена всіма частина проектної документації. Та хоча б тому, що це лише один документ! І потім усім зрозуміло, що туди треба записувати. Але я, все-таки, повторю.

У цьому документі ми повинні розповісти, за допомогою яких програмних засобів виконуються алгоритми, описані в МО, що обробляють інформацію, описану в ІО. Тобто не потрібно дублювати тут інформацію з інших розділів. Тут дається архітектура системи, обґрунтування обраних програмних технологій, їх опис (будь-які системні речі: мови програмування, фреймворки, операційної системи тощо). Також у цьому документі ми описуємо як організовані засоби обробки інформації (черги повідомлень, сховища, засоби резервного копіювання, рішення щодо доступності, всякі пули додатків тощо). У стандарті є докладний опис змісту цього документа, який зрозуміє будь-який фахівець.

Технічне забезпечення (ТО). Не менш улюблена усіма частина проектної документації. Райдужну картину затьмарює лише велика кількість документів, які потрібно розробляти. Усього за стандартом потрібно розробити 22 документи, їх 9 на стадії ТП.

Справа в тому, що стандарт передбачає опис всього технічного забезпечення, включаючи комп'ютерне «залізо» та мережі, інженерні системи і навіть будівельну частину (якщо буде потрібно). А це господарство регламентується величезною кількістю стандартів та нормативних актів, узгоджується у різних організаціях і тому зручніше все дробити на частини та узгоджувати (правити) частинами. У той же час стандарт дозволяє поєднувати деякі документи один з одним, що має сенс робити, якщо усю купу погодить одна людина.

Не забувайте також, що комплекс стандартів якості має на увазі облік та зберігання технічних документів, і наші «книжки» у замовника можуть розійтися різними архівами, залежно від предмета опису. Це ще один аргумент на користь подрібнення документації.

Організаційне забезпечення (ГО). Придушивши в собі нормальне для технаря бажання проскочити цей розділ якнайшвидше, навпаки, розгляну його докладніше. Оскільки, колеги, останнім часом на проектах намітилися погані тенденції, які вимагають внесення ясності у цей розділ.

На стадії ТП розділ містить лише один документ. Опис організаційної структури», в якому ми повинні розповісти замовнику, до чого він має готуватися щодо зміни оргштатної структури. Раптом потрібно організувати новий відділ для експлуатації вашої системи, запровадити нові посади тощо.

На стадії РД з'являються інші, цікавіші документи, які хотілося б розглянути окремо.

Інструкція користувача. Коментарі зайві, я думаю.

Методика (технологія) автоматизованого проектування. У цьому документі за потреби можна помістити опис процесу складання ПЗ, управління версіями, тестування тощо. Але це якщо в ТЗ замовник бажає самостійно здійснювати складання ПЗ. Якщо він цього не вимагає (і не платить за це), то вся ваша внутрішня кухня не його розуму справа, і цей документ робити не потрібно.

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

Опис бізнес-процесів, рольові та посадові інструкції, регламенти роботи – все це ОРД, тобто організаційно-розпорядча документація. Який продукт консалтингового проекту, який у вас, наскільки я розумію, не купували. А купували у вас технічний проект і документацію до нього теж технічну.

Технологічна інструкція є прошарком між ОРД та посібником користувача. РП докладно описує якпотрібно робити ті чи інші дії у системі. Технологічна інструкція говорить про те, якідії необхідно виконувати у тих чи інших випадках, пов'язаних з експлуатацією системи. Грубо кажучи, технологічна інструкція – це короткий дайджест з РП для конкретної посади чи ролі. Якщо у замовника ролі не сформовані або він хоче, щоб ви самі сформували ролі та вимоги до посад, включіть у документ найбагатші ролі, наприклад: оператор, старший оператор, адміністратор. Зауваження замовника на тему «а у нас не так» або «а нам не подобається» повинні супроводжуватися переліком ролей та описом посадових обов'язків. Тому що бізнес-процеси ми не ставимо. Ми ці бізнес-процеси автоматизуємо.

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

Опис технологічного процесу обробки даних (включаючи телеобробку). Жалюгідний рудимент печерної доби, коли були спеціально виділені «Оператори ЕОМ», що згодовують машині перфокарти і упаковують роздрук результату в конвертик. Ця інструкція – для них. Що в неї писати в XXI столітті – я вам точно сказати не можу. Викручуйте самі. Найкраще, це просто забути про цей документ.

Загальносистемні рішення (ОР). Стандартом передбачено 17 документів розділу ГР. По-перше, це майже всі документи попередньої фази ескізного проектування. По-друге, це всілякі кошториси, розрахунки та короткі опис функцій, що автоматизуються. Тобто інформація для людей не з основного ІТ-виробництва, а для допоміжного персоналу – менеджерів, кошторисників, фахівців із закупівель, економістів тощо.

А по-третє, до складу ОР входить мега-документ під назвою «Пояснювальна записка до технічного проекту», який за задумом є Executive Summary, а за фактом багато проектантів пхають в нього взагалі весь корисний зміст стадії ТП. Подібний радикальний підхід буває виправданий і навіть взаємно вигідний і замовнику та виконавцю робіт, але у певних випадках.

Варіанти використання ГОСТ 34

1. Повне і точне дотримання стандарту. Добровільно ніхто, природно, такої хмари документів не писатиме. Тому повний комплект документів готується лише на наполегливе прохання замовника, яке він закріпив у ТЗ та ще договором зверху придавив. У такому разі потрібно розуміти все буквально і віддати замовнику фізичні «книжки», на яких стоятимуть назви документів з таблиці 2 ГОСТ 34.201-89, за винятком зовсім непотрібних, перелік яких ви обов'язково повинні обговорити та закріпити письмово. p align="justify"> Зміст документів також повинен без будь-якої фантазії відповідати РД 50-34.698-90, аж до назви розділів. Щоб у замовника вибухнув мозок, іноді велику систему ділять на підсистеми, і кожної підсистеми випускають окрему проектну документацію. Виглядає це жахливо та нормальному контролю за допомогою земного розуму не підлягає. Особливо щодо інтеграції підсистем. Що значно спрощує приймання. Головне, щоб ви самі при цьому не заплуталися і щоб ваша система таки запрацювала як слід.
2. Ми просто любимо ГОСТи. У великих компаніях люблять стандарти. Тому що вони допомагають людям краще розуміти одне одного. Якщо ваш замовник помічений у любові до порядку та стандартизації, постарайтеся дотримуватись стандартної ідеології ГОСТ при розробці документів, навіть якщо цього не потребує ТЗ. Вас краще зрозуміють і схвалять узгоджуючі фахівці, а ви самі не забудете включити в документацію важливу інформацію, краще бачитимете цільову структуру документів, точніше планувати роботи з їхнього написання та заощадите собі та колегам масу нервів та грошей.
3. Нам начхати на документацію, аби все працювало. Зникаючий вигляд безвідповідального замовника. Подібний погляд на документацію поки що можна зустріти у невеликих і бідних замовників, а також у авторитарних «ідіотократіях», що залишилися з часів перебудови, де бос оточений вірними друзями - директорами, і всі питання вирішуються в особистих розмовах. Ви вільні в подібних умовах забивати на документування взагалі, але краще все-таки приціл не збивати і хоча б схематично наповнювати вмістом документацію. Якщо не цьому замовнику, то наступному передайте (продасте).

Висновок

Ця стаття була про наші ГОСТи на документування АСУ. ГОСТи старі, але, як виявилося, досі дуже корисні в господарстві. Крім деякі явні рудименти, структура документації має властивості повноти і несуперечності, а дотримання стандарту знімає багато проектних ризиків, про існування яких ми можемо спочатку не здогадуватися.

Сподіваюся, викладений матеріал вам був корисний, або, як мінімум, цікавий. Незважаючи на зовнішню нудьгу, документування є важливою та відповідальною роботою, акуратність у якій така ж важлива, як і при написанні гарного коду. Пишіть добрі документи, колеги! А я наступного тижня вирушаю в два поспіль відрядження, тож публікацію нових матеріалів не гарантую (загашника у мене немає, пишу з голови).

Вступ

У сучасному світі щодня з'являється десятки та сотні різних програм, додатків, інформаційних систем. Вони можуть бути розроблені як для державного чи комерційного сектора, так і для звичайних користувачів. 90% всіх користувачів не читає документацію, вважає її нудною, занудною та нецікавою, а відкриває керівництво користувача тільки тоді, коли щось не виходить або розібратися без інструкції зовсім неможливо. Загальноприйнято тепер будувати інтерфейс користувача таким чином, щоб він був інтуїтивно зрозумілий, і користувач міг розібратися з системою, не вдаючись до читання найдовших мануалів. Однак, при роботі з великими замовниками практично завжди необхідно здати певний пакет документів – посібників, інструкцій, проектних рішень, оформлених згідно з ДСТУ.
Коли вперше стикаєшся з написанням документації за ГОСТом, то приходиш у ступор і повний шок, оскільки цих ГОСТів «море» і, як і чого за ними писати стає неясно.
У цій статті розглянуто ГОСТи для написання документації та їх основні моменти.

Які бувають ДСТУ?

Для початку треба розібратися які бувають ГОСТи. Всі лише знають, що ГОСТ — це щось, що розроблялося за Союзу та їх просто нескінченна кількість. Поспішаю вас заспокоїти для сфери IT ГОСТів не так багато, і всі вони, незважаючи на свій термін створення, не втратили своєї актуальності.
Насамперед стандарти для написання документації поділяються на два типи:

1. Міжнародні стандарти (ІSO, IEEE Std);
2. Російські чи Радянські ГОСТи.

Міжнародні стандарти
Міжнародні стандарти застосовуються розробки документації міжнародного рівня. Зазвичай, вони безкоштовні, оскільки розробляються не державними організаціями, але, на відміну наших, розроблені зовсім недавно. Тема міжнародних стандартів дуже широка, тому її буде розглянуто в іншій статті. Тут же торкнулися кілька стандартів, які тісно пов'язані з написанням документації.
Список основних міжнародних стандартів для написання документації:

1. IEEE Std 1063-2001 "IEEE Standard for Software User Documentation" - стандарт для написання посібника користувача;
2. IEEE Std 1016-1998 "IEEE Recommended Practice for Software Design Descriptions" - стандарт для написання технічного опису програми;
3. ISO/IEC FDIS 18019:2004 «Guidelines для створення та керування користувачами для використання програмного забезпечення» - ще один стандарт для написання посібника користувача. У цьому документі є велика кількість прикладів. Так би мовити, це більше схоже на посібник з написання посібника користувача. Початківцям буде особливо корисний;
4. ISO/IEC 26514:2008 "Requirements for designers and developers of user documentation" - ще один стандарт для дизайнерів та розробників користувачів документації.

Міжнародних стандартів насправді дуже багато і в кожній країні вони свої, оскільки один і той самий стандарт не завжди може підійти і європейським, і азіатським компаніям.

Російські стандарти
Російські стандарти розробляються державному рівні. Вони всі абсолютно безкоштовні і кожен із них легко знайти в інтернеті. Для написання документації на програму використовуються дві серії ГОСТів 19 та 34. Саме про них і йтиметься далі.

Чим відрізняються ГОСТи серій 19 та 34?

Перше питання, яке виникає, а чим взагалі ці ГОСТи 19 і 34 відрізняються один від одного.
У ГОСТі 19.781-90 Єдина система програмної документації. Програмне забезпечення систем обробки інформації. Терміни та визначення» вказані визначення:

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

У ГОСТі 34.003-90 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення» зазначено визначення:

1. Автоматизована система (АС) - система, що складається з персоналу та комплексу засобів автоматизації його діяльності, що реалізує інформаційну технологію виконання встановлених функцій.
   Залежно від виду діяльності виділяють, наприклад, такі види АС: автоматизовані системи управління (АСУ), системи автоматизованого проектування (САПР), автоматизовані системи наукових досліджень (АСНІ) та інші.

Залежно від виду керованого об'єкта (процесу) АСУ ділять, наприклад, на АСУ технологічними процесами (АСУТП), АСУ підприємствами (АСУП) і т.д.
Також ГОСТ 34 робить поділ на види забезпечення АС:

1. Організаційне;
2. Методичний;
3. Технічне;
4. Математичне;
5. Програмне забезпечення;
6. інформаційне;
7. Лінгвістичне;
8. Правове;
9. Ергономічне.

У результаті Автоматизована система - це програма, а комплекс видів забезпечення, серед яких є і програмне забезпечення. АС, як правило, несе у собі організаційне рішення під конкретного користувача та замовника, а Програма може бути створена та розтиражована під велику кількість користувачів без прив'язки до будь-якого підприємства.
Тому якщо ви розробляєте документацію на програму, яку створили під конкретне підприємство, ваш ГОСТ 34. Якщо ж пишете документи на масову програму, то ваш ГОСТ 19.

ГОСТ 34

Серія ГОСТів 34 (ГОСТ 34.ххх Стандарти інформаційної технології) складається:

1. ГОСТ 34.201-89 Види, комплектність та позначення документів при створенні автоматизованих систем - цей стандарт встановлює види, найменування, комплектність та номери документів. Є одним із основних документів серії ГОСТів 34. По суті, це базовий документ, тож новачкам необхідно ознайомитися з ним насамперед.
2. ГОСТ 34.320-96 Концепції та термінологія для концептуальної схеми та інформаційної бази - цей стандарт встановлює основні поняття та терміни концептуальних схем та інформаційних баз, що охоплюють розробку, опис та застосування концептуальних схем та інформаційних баз, маніпулювання інформацією, а також опис та процес. Стандарт визначає роль концептуальної схеми. Положення, викладені у ньому, носять рекомендаційний характері і можна використовувати з оцінки систем управління базами даних (СУБД). Цей документ не визначає конкретних методів застосування засобів підтримки концептуальних схем. Описані у стандарті мови концептуальних схем слід розглядати як стандартні.
3. ГОСТ 34.321-96 Інформаційні технології. Система стандартів з баз даних. Еталонна модель управління - цей документ встановлює еталонну модель управління даними.
   Еталонна модель визначає загальну термінологію та поняття, що належать до даних інформаційних систем. Такі поняття використовуються визначення послуг, наданих системами управління базами даних чи системами словників даних.
   Еталонна модель не розглядає протоколи для керування даними.
   Область застосування еталонної моделі включає процеси, що стосуються управління постійними даними та їх взаємодії з процесами, що відрізняються від вимог конкретної інформаційної системи, а також загальні послуги управління даними для визначення, зберігання, пошуку, оновлення, введення, копіювання, відновлення та передачі даних.
4. ГОСТ 34.601-90 Автоматизовані системи. Стадії створення - стандарт встановлює стадії та етапи створення АС.
5. ГОСТ 34.602-89 Технічне завдання створення автоматизованої системи (Натомість ГОСТ 24.201-85) - встановлює склад, зміст, правила оформлення документа «Технічне завдання створення (розвиток чи модернізацію) системи».
   Цей документ є одним із найчастіше використовуваних документів серії ГОСТ 34. При розробці ТЗ цього ГОСТу слід пам'ятати і про інші стандарти, навіть якщо в цьому документі немає посилань на ці стандарти.
6. ГОСТ 34.603–92 Інформаційна технологія. Види випробувань автоматизованих систем – стандарт встановлює види випробувань АС (автономні, комплексні, приймальні випробувань та дослідна експлуатація) та загальні вимоги до їх проведення.
7. РД 50-34.698-90. Автоматизовані системи. Вимоги до змісту документів - одне із найважливіших документів 34 ГОСТа, оскільки у ньому описано зміст практично всіх документів, і навіть опис кожного пункту документа.
8. ГОСТ Р ІСО/МЕК 8824-3-2002 Інформаційна технологія. Абстрактна синтаксична нотація версії один - цей стандарт є частиною абстрактної синтаксичної нотації версії 1 (АСН.1) та встановлює нотацію для специфікації обмежень, визначених користувачем, та табличних обмежень.
9. ГОСТ Р ИСО/МЭК 10746-3-2001 Управління даними та відкрита розподілена обробка.
   У цьому стандарті:
   • визначено, як специфікуються системи відкритої розподіленої обробки (ОРО) з використанням понять, введених у ГОСТ Р ІСО/МЕК 10746-2;
   • ідентифіковані характеристики, якими системи ставляться до систем ОРО.

   У стандарті встановлено каркас для координації розробки стандартів систем ОРО.

10. ГОСТ Р ИСО/МЭК 15271-02 Процеси життєвого циклу програмних засобів - даний ГОСТ необхідно більше, мій погляд, для аналітиків під час проектування і моделюванні АС.
    Цей документ корисний, на мій погляд, у суто освітніх цілях.
11. ГОСТ Р ИСО/МЭК 15910-2002 Процес створення документації користувача програмного засобу - визначає мінімально необхідний процес створення документації користувача всіх видів програмного засобу, що має інтерфейс користувача. Дані види охоплюють друковану документацію (наприклад, посібники користувача та короткі довідкові картки), діалогову (оперативну) документацію, довідковий текст («хелпи») та системи діалогової документації.

Отже, виходячи зі всього вище написаного, видно, що основних документів у 34 ГОСТі 3: ГОСТ 34.201-89, РД 50-34.698-90 та ГОСТ 34.602-89.
При розробці пакета документації, для початку необхідно відкрити ГОСТ 34.201-89 і вибрати стадію створення Ескізний проект, Технічний проект та Робоча документація. Далі слід вибрати документи для розробки, які відповідають стадії створення.

Перелік документів 34 ДСТУ

Стадія створення	Назва документу	Код	Частина проекту	Принад лежнос ть до проект но-кошторисів ній доку мента ції	Принад лежнос ть до експлуа таціон ної до кумен тації	Додаткові вказівки
ЕП	Відомість ескізного проекту	ЕП*	ВР	—	—	—
	Пояснювальна записка До ескізного проекту	П1	ВР	—	—	—
ЕП, ТП	Схема організаційної структури	СО	ВР	—	—	Допускається включати до документа П3 або ПВ
	Схема структурного комплексу технічних засобів	З 1*	ТО	Х	—
	Схема функціональної структури	С2*	ВР	—	—	При розробці документів СО, С1, С2, С3 на стадії ЕП допускається включати їх до документа П1
	спеціалізованих (нових) технічних засобів	О 9	ТО	Х	—	Під час розробки на стадії ТП допускається вмикати у документ П2
	Схема автоматизації	С3*	ТО	Х	—	—
	Технічні завдання на розробку спеціалізованих (нових) технічних засобів	—	ТО	—	—	До складу проекту не входять
ТП	Завдання на розробку санітарно-технічних та інших розділів проекту, пов'язаних зі створенням системи	—	ТО	Х	—	До складу проекту не входять
	Відомість технічного проекту	ТП*	ВР	—	—	—
	Відомість покупних виробів	ВП*	ВР	—	—	—
	Перелік вхідних сигналів та даних	В 1	ВВ	—	—	—
	Перелік вихідних сигналів (документів)	В 2	ВВ	—	—	—
	Перелік завдань на розробку будівельних, електротехнічних, санітарно-технічних та інших розділів проекту, пов'язаних зі створенням системи	У 3	ТО	Х	—	Допускається включати до документа П2
	Пояснювальна записка до технічного проекту	П2	ВР	—	—	Включає план заходів з підготовки об'єкта до введення системи в експлуатацію
	Опис автоматизованих функцій	П3	ВР	—	—	—
	Опис постановки завдань (комплексу завдань)	П4	ВР	—	—	Допускається вмикати у документи П2 чи П3
	Опис інформаційного забезпечення системи	П5	ВВ	—	—	—
	Опис організації інформаційної бази	П6	ВВ	—	—	—
ТП	Опис систем класифікації та кодування	П7	ВВ	—	—	—
	Опис масиву інформації	П8	ВВ	—	—	—
	Опис комплексу технічних засобів	П9	ТО	—	—	Для завдання допускається включати до документа 46 згідно з ГОСТ 19.101
	Опис програмного забезпечення	ПА	ПЗ	—	—	—
	Опис алгоритму (Проектної процедури)	ПБ	МО	—	—	Допускається включати до документів П2, П3 або П4
	Опис організаційної структури	ПВ	ГО	—	—	—
	План розташування	С8	ТО	Х	—	Допускається включати до документа П9
	Відомість обладнання та матеріалів	—	ТО	Х	—	—
	Локальний кошторисний розрахунок	Б2	ВР	Х	—	—
ТП, РД	Проектна оцінка надійності системи	Б1	ВР	—	—	—
	Креслення форми документа (відеокадра)	С9	ВВ	—	Х	На стадії ТП допускається включати до документів П4 чи П5
РД	Відомість власників оригіналів	ДП*	ВР	—	—	—
	Відомість експлуатаційних документів	ЕД*	ВР	—	Х	—
	Специфікація обладнання	В 4	ТО	Х	—	—
	Відомість потреби у матеріалах	В 5	ТО	Х	—	—
	Відомість машинних носіїв інформації	ВМ*	ВВ	—	Х	—
	Масив вхідних даних	О 6	ВВ	—	Х	—
РД	Каталог бази даних	О 7	ВВ	—	Х	—
	Склад вихідних даних (повідомлень)	В 8	ВВ	—	Х	—
	Локальний кошторис	Б3	ВР	Х	—	—
	Методика (технологія) автоматизованого проектування	І1	ГО	—	Х	—
	Технологічна інструкція	І 2	ГО	—	Х	—
	Інструкція користувача	І3	ГО	—	Х	—
	Інструкція з формування та ведення бази даних (набору даних)	І4	ВВ	—	Х	—
	Інструкція з експлуатації КТЗ	ІЕ	ТО	—	Х	—
	Схема з'єднань зовнішніх проводок	С4*	ТО	Х	—	Допускається виконувати в вигляді таблиць
	Схема підключення зовнішніх проводок	С5*	ТО	Х	—	Те саме
	Таблиця з'єднань та підключень	С6	ТО	Х	—	—
	Схема розподілу системи (структурна)	Е1*	ТО	—	—	—
	Креслення загального вигляду	ВО*	ТО	Х	—	—
	Креслення установки технічних засобів	СА	ТО	Х	—	—
	Схема принципова	СБ	ТО	Х	—	—
	Схема структурного комплексу технічних засобів	З 1*	ТО	Х	—	—
	План розташування обладнання та проводок	С7	ТО	Х	—	—
	Опис технологічного процесу обробки даних (включаючи телеобробку)	ПГ	ГО	—	Х	—
	Загальний опис системи	ПД	ВР	—	Х	—
	Програма та методика випробувань (компонентів, комплексів засобів автоматизації, підсистеми, систем)	ПМ*	ВР	—	—	—
	Формуляр	ФО*	ВР	—	Х	—
	Паспорт	ПС*	ВР	—	Х	—
*Документи, код яких встановлений відповідно до вимог стандартів ЄСКД

Примітка до таблиці:

1. У таблиці прийнято такі позначення:
   • ЕП - ескізний проект;
   • ТП - технічний проект;
   • РД – робоча документація;
   • ОР - загальносистемні рішення;
   • ГО — рішення щодо організаційного забезпечення;
   • ТО - рішення з технічного забезпечення;
   • ІВ — рішення щодо інформаційного забезпечення;
   • ПЗ - рішення з програмного забезпечення;
   • МО - рішення з математичного забезпечення.
2. Знак Х — означає приналежність до проектно-кошторисної чи експлуатаційної документації.
3. Номенклатуру документів одного найменування встановлюють залежно від прийнятих під час створення системи проектних рішень.

Коли перелік документів визначено, то в РД 50-34.698-90 слід знайти вибрані документи та розробити їх строго за вказаними пунктами. Усі пункти змісту, які зазначені, обов'язково мають бути у документі.
Якщо розробляється Технічне завдання, відразу потрібно відкрити ГОСТ 34.602-89 і розробити ТЗ строго згідно з пунктами.

ГОСТ 19

Серія ГОСТів 19 (ГОСТ 19.ххх Єдина система програмної документації (ЄСПД)) складається:

1. 1. ГОСТ 19.001-77 Загальні положення - надто загальний документ, практичної користі він не несе. Тому його можна пропустити.
   2. ГОСТ 19781-90 Терміни та визначення - хороший список визначень у галузі програмного забезпечення систем обробки інформації. Крім визначення більше не містить нічого.
   3. ГОСТ 19.101-77 Види програм та програмних документів - один із головних документів 19 ГОСТу. Саме з нього слід розпочинати роботу з 19 ГОСТом, тому що в ньому міститься повний перелік та позначення документів ГОСТу.

Перелік документів 19 Держстандарту

Код	Вид документа	Стадії розробки
		Ескізний проект	Технічний проект	Робочий проект
				компонент	комплекс
—	Специфікація	—	—
05	Відомість власників оригіналів	—	—	—
12	Текст програми	—	—
13	Опис програми	—	—
20	Відомість експлуатаційних документів	—	—
30	Формуляр	—	—
31	Опис застосування	—	—
32	Керівництво системного програміста	—	—
33	Керівництво програміста	—	—
34	Керівництво оператора	—	—
35	Опис мови	—	—
46	Посібник з технічного обслуговування	—	—
51	Програма та методика випробувань	—	—
81	Пояснювальна записка			—	—
90-99	Інші документи

Умовні позначення:
- Документ обов'язковий;
- Документ обов'язковий для компонентів, що мають самостійне застосування;
- Необхідність складання документа визначається на етапі розробки та затвердження технічного завдання;
- - Документ не складають.

1. ГОСТ 19.102-77 Стадії розробки містить опис стадій розробки. Корисний у освітніх цілях. На мою думку, особливої ​​практичної користі не несе.
2. ГОСТ 19.103-77 Позначення програм та програмних документів містить опис присвоєння номера (коду) документу. Навіть після прочитання цього ГОСТу залишається купа питань про те, як привласнити цей номер документу.
3. ГОСТ 19.104-78 Основні написи - встановлює форми, розміри, розташування та порядок заповнення основних написів аркуша затвердження та титульного аркуша у програмних документах, передбачених стандартами ЄСПД, незалежно від способів їх виконання. Оскільки документи 19 ГОСТу оформляються в рамочках, цей документ дуже важливий.
4. ГОСТ 19.105-78 Загальні вимоги до програмних документів – встановлює загальні вимоги до оформлення програмних документів. Вимоги надто загальні. Як правило для розробки документа цей ГОСТ майже не застосовується, тому що вистачає спеціального ГОСТу на документ, але для загальних знань у даний ГОСТ все ж таки краще зазирнути разок.
5. ДЕРЖСТАНДАРТ 19.106-78 Вимоги до програмних документів, виконаних друкованим способом - містить вимоги до оформлення всіх документів 19 ГОСТу.
6. ГОСТ 19.201-78 Технічне завдання, вимоги до змісту та оформлення – встановлює порядок побудови та оформлення технічного завдання на розробку програми чи програмного виробу.

   Пункти ТЗ 34 ГОСТу та 19 ГОСТу відрізняються.

7. ГОСТ 19.601-78 Загальні правила дублювання, обліку та зберігання - загальні правила дублювання, звернення, обліку та зберігання програмних документів. У ГОСТі у кількох пунктах описано як зробити те щоб документи не загубилися.
8. ГОСТ 19.602-78 Правила дублювання, обліку та зберігання програмних документів, викон-х печ. Методом - доповнення до ГОСТу 19.601-78.
9. ГОСТ 19.603-78 Загальні правила внесення змін – встановлює загальні правила внесення змін до програмних документів. По суті описує довгий бюрократичний алгоритм внесення змін до документів.
10. ГОСТ 19.604-78 Правила внесення змін до програмних документів, виконаних друкованим способом - описує порядок роботи та заповнення з Листа реєстрації змін.

Список спеціалізованих ГОСТів, тобто у кожному з них описано зміст та вимоги до певного документа:

1. ГОСТ 19.202-78 Специфікація. Вимоги до змісту та оформлення;
2. ГОСТ 19.301-79 Програма та методика випробувань. Вимоги до змісту та оформлення;
3. ГОСТ 19.401–78 Текст програми. Вимоги до змісту та оформлення;
4. ГОСТ 19.402-78 Опис програми;
5. ГОСТ 19.403-79 Відомість власників оригіналів;
6. ГОСТ 19.404-79 Пояснювальна записка. Вимоги до змісту та оформлення;
7. ГОСТ 19501-78 Формуляр. Вимоги до змісту та оформлення;
8. ГОСТ 19.502-78 Опис застосування. Вимоги до змісту та оформлення;
9. ГОСТ 19.503-79 Керівництво системного програміста. Вимоги до змісту та оформлення;
10. ГОСТ 19.504-79 Керівництво програміста. Вимоги до змісту та оформлення;
11. ГОСТ 19.505-79 Керівництво оператора. Вимоги до змісту та оформлення;
12. ГОСТ 19.506-79 Опис мови. Вимоги до змісту та оформлення;
13. ГОСТ 19.507-79 Відомість експлуатаційних документів;
14. ГОСТ 19.508-79 Посібник із технічного обслуговування. Вимоги до змісту та оформлення.

Порядок роботи з 19 ГОСТом:

1. У ГОСТі 19.101-77 вибрати документ та його код відповідно до стадії розробки.
2. Відповідно до ГОСТу 19.103-77 присвоїти номер документу.
3. Потім за ГОСТами 19.104-78 та 19.106-78 оформити документ.
4. Зі спеціалізованого списку ГОСТів слід вибрати той, який відповідає документу, що розробляється.

Висновок

ГОСТ - це не страшно та нескладно! Головне зрозуміти, що потрібно написати і який для цього ДЕРЖСТАНДАРТ використовується. Наші основні ГОСТи 19 та 34 для написання документації дуже старі, але й досі актуальні. Написання документації за стандартом знімає багато питань між виконавцем та замовником. Отже, несе в собі економію часу та грошей.

Дата введення 01.01.92

Цей стандарт поширюється на автоматизовані системи (АС), що використовуються в різних видах діяльності (дослідження, проектування, управління тощо), включаючи їх поєднання, що створюються в організаціях, об'єднаннях та на підприємствах (далі – організаціях).

Стандарт встановлює стадії та етапи створення АС. У додатку 1 наведено зміст робіт кожному етапі.

1. Загальні положення

2. Стадії та етапи створення АС

Додаток 1 (довідковий)

Додаток 2 (довідковий)

1. ЗАГАЛЬНІ ПОЛОЖЕННЯ

1.1. являє собою сукупність упорядкованих у часі, взаємопов'язаних, об'єднаних у стадії та етапи робіт, виконання яких необхідне та достатньо для створення АС, що відповідає заданим вимогам.

1.2. Стадії та етапи створення АС виділяються як частини процесу створення з міркувань раціонального планування та організації робіт, що закінчуються заданим результатом.

1.3. Роботи з розвитку АС здійснюють за стадіями та етапами, що застосовуються для створення АС.

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

Перелік організацій, що у роботах зі створення АС, наведено у додатку 2.

2. СТАДІЇ ТА ЕТАПИ СТВОРЕННЯ АС

2.1. Стадії та етапи створення АС у загальному випадку наведені у таблиці.

Стадії	Етапи робіт
1. Формування вимог до АС	1.1. Обстеження об'єкта та обґрунтування необхідності створення АС
	1.2. Формування вимог користувача до АС
	1.3. Оформлення звіту про виконану роботу та заявки на розробку АС (тактико-технічного завдання)
2. Розробка концепції АС	2.1. Вивчення об'єкту
	2.2. Проведення необхідних науково-дослідних робіт
	2.3. Розробка варіантів концепції АС та вибір варіанта концепції АС, що задовольняє вимогам користувача
	2.4. Оформлення звіту про виконану роботу
3. Технічне завдання	3.1. Розробка та затвердження технічного завдання на створення АС
4. Ескізний проект	4.1. Розробка попередніх проектних рішень щодо системи та її частин
	4.2. Розробка документації на АС та її частини
5. Технічний проект	5.1. Розробка проектних рішень щодо системи та її частин
	5.2. Розробка документації на АС та її частини
	5.3. Розробка та оформлення документації на постачання виробів для комплектування АС та (або) технічних вимог (технічних завдань) на їх розробку
	5.4. Розробка завдань на проектування у суміжних частинах проекту об'єкта автоматизації
6. Робоча документація	6.1. Розробка робочої документації на систему та її частини
	6.2. Розробка або адаптація програм
7. Введення в дію	7.1. Підготовка об'єкта автоматизації до введення АС у дію
	7.2. Підготовка персоналу
	7.3. Комплектація АС виробами, що поставляються (програмними та технічними засобами, програмно-технічними комплексами, інформаційними виробами)
	7.4. Будівельно-монтажні роботи
	7.5. Пуско-налагоджувальні роботи
	7.6. Проведення попередніх випробувань
	7.7. Проведення дослідної експлуатації
	7.8. Проведення приймальних випробувань
8. Супровід АС	8.1. Виконання робіт відповідно до гарантійних зобов'язань
	8.2. Післягарантійне обслуговування

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

Допускається виключати стадію «Ескізний проект» та окремі етапи робіт на всіх стадіях, об'єднувати стадії «Технічний проект» та «Робоча документація» в одну стадію «Техноробочий проект». Залежно від специфіки створюваних АС та умов їх створення допускається виконувати окремі етапи робіт до завершення попередніх стадій, паралельне виконання виконання етапів робіт, включення нових етапів робіт.

ДОДАТОК 1.Довідкове

1. На етапі 1.1 «Обстеження об'єкта та обґрунтування необхідності створення АС» у загальному випадку проводять:

• збір даних про об'єкт автоматизації та здійснювані види діяльності;
• оцінку якості функціонування об'єкта та здійснюваних видів діяльності, виявлення проблем, вирішення яких можливе засобами автоматизації;
• оцінку (техніко-економічної, соціальної тощо) доцільності створення АС.

2. На етапі 1.2 "формування вимог користувача до АС" проводять:

• підготовку вихідних даних для формування вимог до АС (характеристика об'єкта автоматизації, опис вимог до системи, обмеження допустимих витрат на розробку, введення в дію та експлуатацію, ефект, що очікується від системи, умови створення та функціонування системи);
• формулювання та оформлення вимог користувача до АС.

3. На етапі 1.3 «Оформлення звіту про виконану роботу та заявки на розробку АС (тактико-технічного завдання)» проводять оформлення звіту про виконані роботи на даній стадії та оформлення заявки на розробку АС (тактико-технічного завдання) або іншого документа, що її замінює. аналогічним змістом.

4. На етапах 2.1 «Вивчення об'єкта» та 2.2 «Проведення необхідних науково-дослідних робіт» організація-розробник проводить детальне вивчення об'єкта автоматизації та необхідні науково-дослідні роботи (НДР), пов'язані з пошуком шляхів та оцінкою можливості реалізації вимог користувача, оформлюють та затверджують звіти про НДР.

5. На етапі 2.3 «Розробка варіантів концепції АС та вибір варіанта концепції АС, який відповідає вимогам користувача» у загальному випадку проводять розробку альтернативних варіантів концепції створюваної АС та планів їх реалізації; оцінку необхідних ресурсів на їх реалізацію та забезпечення функціонування; оцінку переваг та недоліків кожного варіанту; зіставлення вимог користувача та характеристик запропонованої системи та вибір оптимального варіанту; визначення порядку оцінки якості та умов приймання системи; оцінку ефектів, які отримують від системи.

6. На етапі 2.4 «Оформлення звіту про виконану роботу» готують та оформляють звіт, що містить опис виконаних робіт на стадії, опис та обґрунтування запропонованого варіанта концепції системи.

7. На етапі 3.1 «Розробка та затвердження технічного завдання на створення АС» проводять розробку, оформлення, погодження та затвердження технічного завдання на АС та, за необхідності, технічних завдань на частини АС.

8. На етапі 4.1 «Розробка попередніх проектних рішень щодо системи та її частин» визначають: функції АС; функції підсистем, їх цілі та ефекти; склад комплексів завдань та окремих завдань; концепції інформаційної бази, її укрупнену структуру; функції системи керування базою даних; склад обчислювальної системи; функції та параметри основних програмних засобів.

9. На етапі 5.1 «Розробка проектних рішень за системою та її частинами» забезпечують розробку загальних рішень за системою та її частинами, функціонально-алгоритмічною структурою системи, за функціями персоналу та організаційною структурою, за структурою технічних засобів, за алгоритмами розв'язування задач та мовами, що застосовуються , з організації та ведення інформаційної бази, системи класифікації та кодування інформації, щодо програмного забезпечення.

10. На етапах 4.2 та 5.2 «Розробка-документації на АС та її частини» проводять розробку, оформлення, погодження та затвердження документації в обсязі, необхідному для опису повної сукупності прийнятих проектних рішень та достатньому для подальшого виконання робіт зі створення АС. Види документів – за ГОСТ 34.201.

11. На етапі 5.3 «Розробка та оформлення документації на постачання виробів для комплектування АС та (або) технічних вимог (технічних завдань) на їх розробку» проводять підготовку та оформлення документації на постачання виробів для комплектування АС; визначення технічних вимог та складання ТЗ на розробку виробів, що не виготовляються серійно.

12. На етапі 5.4 «Розробка завдань на проектування у суміжних частинах проекту автоматизації» здійснюють розробку, оформлення, погодження та затвердження завдань на проектування у суміжних частинах проекту об'єкта автоматизації для проведення будівельних, електротехнічних, санітарно-технічних та інших підготовчих робіт, пов'язаних із створенням АС.

13. На етапі 6.1 «Розробка робочої документації на систему та її частини» здійснюють розробку робочої документації, що містить усі необхідні та достатні відомості для забезпечення виконання робіт із введення АС у дію та її експлуатації, а також для підтримання рівня експлуатаційних характеристик (якості) системи відповідно до прийнятих проектних рішень, її оформлення, погодження та затвердження. Види документів – за ГОСТ 34.201.

14. На етапі 6.2 «Розробка або адаптація програм» проводять розробку програм та програмних засобів системи, вибір, адаптацію та (або) прив'язку придбаних програмних засобів, розробку програмної документації відповідно до ГОСТ 19.101.

15. На етапі 7.1 «Підготовка об'єкта автоматизації до введення АС у дію» проводять роботи з організаційної підготовки об'єкта автоматизації до введення АС у дію, у т. ч.: реалізацію проектних рішень щодо організаційної структури АС; забезпечення підрозділів об'єкта управління інструктивно-методичними матеріалами; Використання класифікаторів інформації.

16. На етапі 7.2 «Підготовка персоналу» проводять навчання персоналу та перевірку його здатності забезпечити функціонування АС.

17. На етапі «Комплектація АС виробами, що постачаються» забезпечують отримання комплектуючих виробів серійного та одиничного виробництва, матеріалів та монтажних виробів. Проводять вхідний контроль якості.

18. На етапі 7.4 "Будівельно-монтажні роботи" проводять: виконання робіт з будівництва спеціалізованих будівель (приміщень) для розміщення технічних засобів та персоналу АС; спорудження кабельних каналів; виконання робіт з монтажу технічних засобів та ліній зв'язку; випробування змонтованих технічних засобів; здачу технічних засобів для проведення пусконалагоджувальних робіт.

19. На етапі 7.5 «Пусконалагоджувальні роботи» проводять автономне налагодження технічних та програмних засобів, завантаження інформації до бази даних та перевірку системи її ведення; комплексне налагодження всіх засобів системи.

20. На етапі 7.6 "Проведення попередніх випробувань" здійснюють:

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

21. На етапі 7.7 «Проведення дослідної експлуатації» проводять дослідну експлуатацію АС; аналіз результатів дослідної експлуатації АС; доопрацювання (за потреби) програмного забезпечення АС; додаткове налагодження (за потреби) технічних засобів АС; оформлення акта про завершення дослідної експлуатації

22. На етапі 7.8 "Проведення приймальних випробувань" проводять:

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

23. На етапі 8.1 "Виконання робіт відповідно до гарантійних зобов'язань" здійснюють роботи з усунення недоліків, виявлених при експлуатації АС протягом встановлених гарантійних термінів, внесення необхідних змін до документації на АС.

24. На етапі 8.2 «Післегарантійне обслуговування» здійснюють роботи з:

• аналізу функціонування системи;
• виявлення відхилень фактичних експлуатаційних характеристик АС від проектних значень;
• встановлення причин цих відхилень;
• усунення виявлених недоліків та забезпечення стабільності експлуатаційних характеристик АС;
• внесення необхідних змін до документації на АС.

ДОДАТОК 2. Довідкове

ПЕРЕЛІК ОРГАНІЗАЦІЙ, ЩО БЕРИТЬ УЧАСТЬ У РОБОТАХ ЩОДО СТВОРЕННЯ АС

1. Організація-замовник (користувач), для якої створиться АС та яка забезпечує фінансування, приймання робіт та експлуатацію АС, а також виконання окремих робіт зі створення АС.

2. Організація-розробник, яка здійснює роботи зі створення АС, представляючи замовнику сукупність науково-технічних послуг на різних стадіях та етапах створення, а також розробляючи та поставляючи різні програмні та технічні засоби АС.

3. Організація-постачальник, яка виготовляє та постачає програмні та технічні засоби на замовлення розробника або замовника.

4. Організація-генпроектувальник об'єкта автоматизації.

5. Організації-проектувальники різних частин проекту об'єкта автоматизації щодо будівельних, електротехнічних, санітарно-технічних та інших підготовчих робіт, що з створенням АС.

6. Організації будівельні, монтажні, налагоджувальні та інші.

Примітки:

1. Залежно від умов створення АС можливі різні поєднання функцій замовника, розробника, постачальника та інших організацій, що у роботах зі створення АС.

2. Стадії та етапи виконуваних ними робіт зі створення АС визначаються на підставі цього стандарту.

ІНФОРМАЦІЙНІ ДАНІ

1. Розроблено та внесено Державним комітетом СРСР з управління якістю продукції та стандартами

РОЗРОБНИКИ

Ю.Х. Вермішів, д-р техн. наук; Я.Г. Віленчик; В.І. Воропаєв, д-р техн. наук; Л.М. Зайденберг, канд. техн. наук; Ю.Б. Ірз, канд. техн. наук; В.Д. Костюков, канд. техн. наук; М.А. Лабутін, конд. техн. наук; Н.П. Лєсковська; І.С. Мітяєв; В.Ф. Попов (керівник теми); С.В. Гаршина; А.І. Глуховіря; Ю.Г. Жуків, канд техн. наук; З.П. Задубовська; В.Г. Іванов; Ю.І. Караванів, канд техн. наук; А.А. Клочків; В.Ю. Корольов; В.І. Махнач, канд. техн. наук; С.Б. Михалєв, д-р техн. наук; В.М. Петрикевич; В.А. Рахманов, канд. екон. наук; А.А. Рат'кович; Р.С. Седегов, д-р екон. наук; Н.В. Степанчикова; М.С. Суровець; А.В. Флегенти; Л.О. Хвілевський, канд. техн. наук; В.К. Чістів, канд. екон. наук

2. ЗАТВЕРДЖЕНИЙ І ВВЕДЕНИЙ У ДІЮ Постановою Державного комітету СРСР з управління якістю продукції та стандартів від 29.12.90 № 3469

М. Острогорський, 2008

Щоб успішно застосовувати ГОСТ 34, необхідно розуміти, як, з погляду цього комплексу стандартів, влаштована автоматизована система. В іншому випадку ми не побачимо в гостях нічого крім довгого списку документів із загадковими назвами, а вимоги до їх утримання вкотре переконають нас у тому, що багато мудростей багато печалі. Тому перш ніж обговорювати самі документи, ми повинні розібратися в тому, що є предметом документування.

Автоматизована система, її функції та завдання

Визначення автоматизованої системи

ГОСТ 34.003-90 містить таке визначення автоматизованої системи: система, що складається з персоналу та комплексу засобів автоматизації його діяльності, що реалізує інформаційну технологію виконання встановлених функцій. Що це визначення означає насправді? Розібратися в цьому можна, лише враховуючи інші визначення цього стандарту і зіставляючи їх один з одним. Чим ми зараз і займемося.

Цілі діяльності

Автоматизована система може існувати лише там, де є персонал, зайнятий певною діяльністю. Як правило, йдеться про діяльність, результати якої корисні комусь незалежно від інструментів, що застосовуються. Наприклад, до театральної каси я звертаюся за квитком, і мене цілком влаштує, якщо касирка випише мені його ручкою на бланку, аби мене по ньому пустили до зали. Касирші, за великим рахунком, теж байдуже, як саме виготовити квиток. Її влаштує будь-який спосіб, якщо він буде не надто трудомісткий і забезпечить можливість продати мені квиток. Інакше кажучи, ми маємо з нею спільну мету. У ГОСТ 34.003-90 для її позначення використовується термін мета діяльності. Щоразу, коли черговий глядач відходить від віконця з квитком у руках, а театр стає трохи багатшим, ця мета діяльності досягається.

Функції автоматизованої системи

Цілей діяльності може бути (і, як правило, буває) кілька. Будь-який корисний поза самої діяльності результат можна вважати її метою. Так, якщо касирка не тільки продає квиток, а й наприкінці робочого дня складає для начальства звіт про продаж, складання щоденного звіту може розглядатися як ще одна мета діяльності.

Якщо ми поставимо касирці на стіл комп'ютер та принтер, а начальник касирки видасть наказ, щоб вона набирала квитки та звіти у текстовому редакторі, а друкувала їх на принтері, то вийде автоматизована система. За сучасними уявленнями, дуже примітивна, формально гостовському визначенню вона задовольнятиме. Зверніть увагу, що цілі діяльності внаслідок впровадження автоматизованої системи не змінилися, змінився лише спосіб їх досягнення. Те, що раніше робилося просто так, тепер робиться в рамках автоматизованої системи. Сукупність дій автоматизованої системи, спрямовану на досягнення певної мети, згідно з ГОСТ 34.003-90, називається її функцією. Зверніть увагу: як би до цього не ставитися, персонал вважається частиною системи.

Функція автоматизованої системи — фундаментальне поняття у ГОСТ 34. Автоматизована система розглядатиметься, насамперед, як сума своїх функцій і вже потім як купа «софту» та «заліза». Найголовніше, що робить система, а з чого вона складається, другорядне.

Сказане вище могло привести читача до висновку, що кожній меті діяльності в автоматизованій системі відповідає одна і лише одна функція. Таку систему легко собі уявити, але практика різноманітніша. З одного боку, які завжди діяльність автоматизується повністю. Деякі цілі і після впровадження автоматизованої системи доводиться домагатися вручну. З іншого боку, оскільки один і той же результат у різних умовах може досягатися різними способами, на одну мету діяльності в автоматизованій системі можуть бути спрямовані кілька функцій, скажімо, продаж квитка в касі та продаж квитка через Інтернет. Крім того, будь-яка автоматизована система потребує певного обслуговування, тому доводиться вводити поняття допоміжної функції. Типовий приклад – створення резервної копії даних.

Завдання автоматизованої системи

Загалом у разі виконання функції частина роботи виконується персоналом, а частина технікою, скажімо, квиток виводиться на друк автоматично, а видається покупцю касиркою вручну. Послідовність автоматичних (sic) дій, що веде до результату заданого виду, у ГОСТ 34.003-90 називається завданням.

Тут визначення завдання процитоване не зовсім точно, але поки нам буде достатньо і такого, зрештою, будь-кому прочитати стандарт самостійно. Важливо, що завдання — найбільш чітко формалізована частина автоматизованої діяльності. Можна уявити функцію, що виконується повністю автоматично, наприклад, згадане вище резервне копіювання. У такому разі функція зводиться до одного завдання.

Одне й те завдання може вирішуватися і під час різних функцій. Наприклад, якщо в автоматизованій системі є кілька функцій для продажу квитка, виконання кожної з них може в якийсь момент вимагати виведення квитка друк.

Склад автоматизованої системи

Підсистеми

Якщо автоматизована система досить складна, її ділять на підсистеми. Що означає, досить складно, сказати досить складно. У теорії систем описані різні рівні та критерії складності. На практиці необхідність виділення в автоматизованій системі кількох підсистем часто буває викликана організаційними та фінансовими причинами, наприклад, підсистеми розробляють та вводять в експлуатацію послідовно.

Хоча в ГОСТ 34 термін підсистема використовується багаторазово, формального визначення цього поняття там начебто немає. Досвід підказує, що підсистема - це частина автоматизованої системи, яка також задовольняє визначення автоматизованої системи, зокрема має повноцінні функції.

Повернувшись, наприклад, з продажем квитків, ми можемо прийняти рішення, що автоматизована система складається з двох підсистем: підсистеми продажу квитків та підсистеми формування щоденних звітів. Давайте тільки для більшої чіткості домовимося, що квитки касирки набирають у текстовому редакторі, а звіти – в електронних таблицях.

Компоненти

Виділення цілей діяльності, функцій автоматизованої системи та при необхідності її підсистем багато в чому суб'єктивне і поставлене у залежність від погляду суб'єкта, який вирішив цим зайнятися. Якщо певний результат є важливим у контексті розв'язуваного завдання, ми можемо вважати його метою, а інакше ігнорувати. Розбивати автоматизовану систему на підсистеми ми теж будемо так, як нам зручно, аби наші рішення не суперечили змісту цього поняття.

Компоненти - це частини, з яких ми в об'єктивній реальності будуємо автоматизовану систему. p align="justify"> Система фізично складається зі своїх компонентів, тому розподіл автоматизованої системи на компоненти носить найбільш об'єктивний характер.

Кожен компонент ми купуємо, монтуємо та підключаємо (якщо це обладнання), встановлюємо (якщо це програма) та обслуговуємо окремо від інших компонентів. Ми купили та поставили на стіл комп'ютер – це компонент. Розробили спеціальний текстовий редактор для набору квитків – ще один компонент. Завантажили з Інтернету безкоштовні електронні таблиці — знов-таки компонент. І навіть сама касирка до певної міри теж компонент автоматизованої системи.

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

Види забезпечення

Одне з найскладніших понять для користувача-початківця ГОСТ 34 — вид забезпечення. Що за таке забезпечення? Чи можна його побачити чи помацати? Продати чи купити?

Кожен вид забезпечення поєднує у собі компоненти чи технічні рішення певного характеру. У ГОСТ 34 згадується багато різних видів забезпечення, послідовно описувати тут кожен з них ми не будемо, а перерахуємо лише найпомітніші:

• інформаційне забезпечення - всі дані та метадані, з якими працює система;
• програмне забезпечення - всі програми, що входять до складу системи;
• технічне забезпечення - всі технічні засоби (інакше кажучи, обладнання, апаратура), що входять до складу системи.

Повторимо ще раз це не всі види забезпечення. Ми навіть не можемо впевнено сказати, що вони найважливіші. Наприклад, для автоматизованих систем управління технологічними процесами (АСУТП) велике значення має метрологічне забезпечення. Багато автоматизованих систем потребують складного математичного та лінгвістичного забезпечення. Але уявити автоматизовану систему, яка була б повністю позбавлена ​​одного з трьох перерахованих вище видів забезпечення, важко (вправа: спробуйте).