WEBURSITET.RU

1. Пастка перша. Користувач.
2. Пастка друга. Концепція.
3. Пастка третя. Лінгвістичне забезпечення.
4. Пастка четверта. Вимоги безпеки.

11.12.2014 1:03

ГОСТ - це законодавчо затверджений феншуй!
( Народна творчість )

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

Одна з цих небезпек - термінологія. Аналітик, вихований на книгах Вігерса, шанує BABOK і поклоняється шаблонами RUP, повинен бути готовий до наступання на термінологічні граблі буквально з перших абзаців стандарту.

Пастка перша. Користувач.

Ось, наприклад, дивиться аналітик на опис життєвого циклу процесу створення системи, і бачить в ньому перший етап:
1 Формування вимог до АС
1.1 Обстеження об'єкта та обгрунтування необхідності створення АС
1.2 Формування вимог користувача до АС

При вигляді цього тексту аналітик радіє: такі знайомі слова - вимоги, користувач. І робить висновок:

«На базі отриманих даних необхідно виявити основні функціональні і призначені для користувача вимоги до АС.» (Цитата звідси http://www.it-gost.ru/content/view/93/51/ ).

Все прямо по Вігерсу - ось же вони, ці вимоги, на картинці!

Але ж ні. Тут його підстерігає перша пастка.

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

Тобто в більш звичній сучасним аналітикам термінології вимоги користувача по ГОСТу - це бізнес-вимоги найвищого рівня.

А значить, між «вимогами користувача» по ГОСТу і «призначеними для користувача вимог» по Вігерсу лежить прірва.

Пастка друга. Концепція.

Подолавши перші граблі, аналітик йде за стандартом далі. Другий етап:
2 Розробка концепції АС.
2.1 Вивчення об'єкта
2.2 Проведення науково-дослідних робіт
2.3 Розробка варіантів концепції АС, що задовольняють вимогам користувача.

І знову знайоме слово - Концепція! Це ж знайомий і звичний Vision, або, по Вігерсу, «Документ про спосіб і межах проекту».

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

Тобто метою розробки концепції по ГОСТу є надання інформації, що дозволяє Великому Босу порівняти кілька узагальнених варіантів реалізації системи. При цьому для кожного варіанта, крім «плюсів, мінусів і підводних каменів», повинна бути надана оцінка необхідних ресурсів.

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

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

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

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

Пастка третя. Лінгвістичне забезпечення.

Чи часто ви бачите в ТЗ в розділі «Вимоги до лінгвістичного забезпечення» щось на зразок цього?

Взаємодія користувача з ПК повинно здійснюватися російською мовою.

Або цього.

Розробка прикладного програмного забезпечення повинна вестися з використанням мов високого рівня. (Цікаво, без цієї чарівної фрази в ТЗ всю систему доведеться писати на асемблері?)

Часто? Не дивно. Адже ці формулювання потрапили навіть в навчальні курси авторитетних навчальних центрів.

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

Що ж мали на увазі розробники ГОСТу, коли писали ось це? «Для лінгвістичного забезпечення системи приводять вимоги до застосування в системі мов програмування високого рівня, мов взаємодії користувачів і технічних засобів системи, а також вимоги до кодування і декодування даних, до мов введення-виведення даних, мов маніпулювання даними, засобам опису предметної області (об'єкта автоматизації), до способів організації діалогу. »

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

Схожа ситуація була з кодуванням і декодуванням даних, мовами введення-виведення і мовами маніпулювання даними. Широко поширених мережевих протоколів, вбудованих в кожну ОС, не було. SQL тільки починав свій переможний хід , Причому десь далеко за кордоном. Більшість протоколів взаємодії різних компонентів системи розробникам систем доводилося вигадувати самостійно. Ці протоколи і малися на увазі під «кодуванням і декодуванням даних».

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

Пастка четверта. Вимоги безпеки.

А ну-ка, швидко, не заглядаючи в ГОСТ, скажіть, що у вас написано в розділі «Вимоги безпеки»? Щось про права користувачів і захисту від несанкціонованого доступу?

Вітаю. Ви просто не читали ГОСТ. Дивно, але, судячи з великої кількості ТЗ, цей розділ майже ніхто не читає. Все ж і так знають, що таке інформаційна безпека! Але ... звідки ви взяли слово «інформаційна»?

Я б не писав про цю пастці, настільки вона примітивна. Але на ці граблі наступають не тільки початківці, але навіть найдосвідченіші аналітики - ті, хто виступає на семінарах і конференціях і вчить інших розробляти ТЗ!

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

Так-так, інформаційна безпека теж дуже важлива, але вона зовсім в іншому розділі.

Очевидно, що цей розділ дістався нам у спадок від епохи великих (і важких) обчислювальних машин і залізних «призначених для користувача інтерфейсів» на тумблерах і лампочках. Зараз в абсолютній більшості випадків він просто не потрібен.

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

Так що будьте обережні, колеги, і уникайте цих пасток. А ще краще по можливості уникайте розробки «всього по ГОСТу».