Терминологические ловушки ГОСТ 34

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

Тернист и сложен путь аналитика, впервые выбравшего ГОСТ 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…

Ловушка четвёртая. Требования безопасности.

А ну-ка, быстро, не заглядывая в ГОСТ, скажите, что у вас написано в разделе «Требования безопасности»? Что-то о правах пользователей и защите от несанкционированного доступа?

Поздравляю. Вы просто не читали ГОСТ. Удивительно, но, судя по большому количеству ТЗ, этот раздел почти никто не читает. Все ведь и так знают, что такое информационная безопасность! Но… откуда вы взяли слово «информационная»?

Я бы не писал об этой ловушке, настолько она примитивна. Но на эти грабли наступают не только начинающие, но даже самые опытные аналитики — те, кто выступает на семинарах и конференциях и учит других разрабатывать ТЗ!

Между тем ГОСТ гласит: «В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок.»

Да-да, информационная безопасность тоже очень важна, но она совсем в другом разделе.

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

Скорее всего, причиной массового попадания в эту ловушку стало массовое же использование шаблонов документов. Аналитик получает задание, скачивает готовый шаблон, содержащий только заголовки, и начинает его заполнять, руководствуясь своим пониманием терминов. А термины любят пошутить, особенно с аналитиками.

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