Устарели ли стандарты ГОСТ 34?::БИТ 09.2018
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
апрель    2019
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
27
28
30

показать все 

Новости партнеров

24.04.2019

Дарим скидку всем: билеты на Connected Car Conference в полцены

Читать далее 

24.04.2019

Выставка SAPE 2019: наглядно о безопасности труда

Читать далее 

24.04.2019

Конференция “Уберизация экономики: модели, рынки, тренды”

Читать далее 

24.04.2019

На Форуме «Российский софт: эффективные решения» всесторонне обсудили национальную кибербезопасность

Читать далее 

показать все 

Статьи

23.04.2019

Компании перед лицом меняющегося мира

Читать далее 

23.04.2019

Как защитить интеллектуальную собственность?

Читать далее 

23.04.2019

Зачем компьютеру этика?

Читать далее 

23.04.2019

Клиенты в интернете. Опрос

Читать далее 

23.04.2019

Кто будет править миром? Опрос

Читать далее 

22.03.2019

5 вопросов о «цифре»

Читать далее 

21.03.2019

Все под контролем

Читать далее 

12.03.2019

Тренды по UC

Читать далее 

21.04.2017

Язык цифр или внутренний голос?

Читать далее 

16.04.2017

Планы – ничто, планирование – все. Только 22% компаний довольны своими инструментами для бизнес-планирования

Читать далее 

показать все 

Устарели ли стандарты ГОСТ 34?

Главная / Архив номеров / 2018 / Выпуск №09 (82) / Устарели ли стандарты ГОСТ 34?

Рубрика: Госстандарты


Марина Аншинапредседатель правления Российского Союза ИТ- директоров, президент фонда ФОСТАС

Устарели ли стандарты ГОСТ 34?

Устарели ли стандарты ГОСТ 34?Подходит ли ГОСТ 34 для ИТ-проектов или надо использовать более современные стандарты?

Вступление, или Как я прокололась

Мне очень стыдно! Несколько лет я всем объясняла, что стандарты ГОСТ 34, разработанные в начале 90-х годов прошлого века, сильно устарели. Поэтому при их использовании в современных проектах разработки и внедрения программных систем возникают трудности и несоответствия, такие как:

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

Хотя все это действительно так, ГОСТ 34, возможно, тут вовсе не виноват.

Причина моего заблуждения кроется в мастер-классе, который я еще лет десять тому назад проводила для крупного системного интегратора, озабоченного проблемами внедрения SAP R3. Клиентами этой компании были в основном государственные организации. И для них по условиям тендеров требовалось вести проект в соответствии со стандартами ГОСТ 34. А всем известно, что компания SAP для повышения внедряемости своей системы разработала методологию ASAP, которая, что вполне естественно, основана на международных стандартах ИСО/МЭК 15288, 15289 и 12207.

Кстати, сразу отмечу, что эти стандарты постоянно обновляются. Вот и в течение последних лет появились их новые версии. У внедренцев ум заходил за разум, когда они пытались подружить эти стандарты с ГОСТ 34, и они попросили меня помочь разобраться с проблемой.

Мы провели двухдневный мастер-класс, на котором подробно разбирали стандарты и лучшие практики внедрения программных систем, в результате которого пришли к выводу, что вышеупомянутые стандарты не согласованы, образно говоря, перпендикулярны друг другу. Поэтому дешевле выбрать один из них – понятно, что это должен быть ГОСТ 34, как требует Заказчик, – и работать по нему, пусть и повышая вероятность наступления рисков, угрожающих проекту.

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

При анализе международных стандартов я, как и многие мои коллеги, не использовала переводы, а обращалась к первоисточникам. Ведь известно, что даже самый лучший перевод теряет порядка 20% смысла. Именно поэтому достаточно длительное время я была уверена, что необходимо агитировать специалистов использовать новые (постоянно обновляемые) международные стандарты взамен устаревших отечественных, которые с 90-х годов не обновлялись и успели одряхлеть даже в терминологическом смысле.

Как помогли студенты

Полгода назад мне выпала честь прочитать курс по стандартам ИТ в Высшей школе бизнеса МГУ магистрам второго года, которые обучались по специальности «Менеджмент ИТ». Нынешние студенты вообще народ капризный, в ВШБ – особенно. А стандарты – тема довольно сухая. И я стала размышлять о том, как бы сделать так, чтобы студенты не заснули на моих занятиях, но при этом рассказать им о стандартах.

Cтандарты – тема довольно сухая. И я стала размышлять о том, как бы сделать так, чтобы студенты не заснули на моих занятиях, но при этом рассказать им о стандартах

Я придумала игру в экспертизу. Вынесла основные положения стандартов ГОСТ 34 о техническом задании и стадиях разработки ПО на слайды. Разделила студентов на две группы: первая должна была доказательно отстаивать актуальность стандарта, вторая – соответственно, то, что он безвозвратно устарел. «Заманухой» служил зачет-автомат для наиболее успешных студентов из первой и второй групп.

Все результаты занятия были как для меня, так и для студентов, совершенно неожиданными:

  1. ГОСТ 34 до сих пор во многом обгоняет подходы к ИТ, и большинство его положений, если осовременить терминологию, абсолютно актуальны.
  2. Подобная форма обсуждения стандарта позволяет погрузиться в него намного глубже, чем все другие формы изучения, включая использование в реальных проектах.
  3. Занятие, проведенное по такому принципу, вовлекает в обучение всех, даже самых ленивых и незаинтересованных студентов (многие из них признались, что это было самое интересное занятие за все время их обучения).

Конечно, я решила не останавливаться на достигнутом. И следующее занятие мы посвятили подобному же пристальному разбору ГОСТ Р ИСО/МЭК 12207 – 2010. Результаты были еще более ошеломляющими:

  1. ГОСТ 12207 противоречит российскому законодательству.
  2. Одни и те же термины переведены в нем по-разному, и мы со студентами предприняли настоящее расследование, как это могло произойти. В результате пришли к выводу, что к переводу еще 1995 года просто добавили новые куски, которые переводили другие люди, не озабоченные сохранением терминологии. Поэтому получился не просто винегрет, а нечто совершенно «несъедобное».

И равнодушных среди студентов не наблюдалось.

Очевидно, что форма журнальной статьи не позволяет применить тот же прием, что так хорошо зарекомендовал себя на занятиях, и обсудить стандарт в полном объеме. Поэтому хочу просто познакомить вас с некоторыми интересными выводами.

Сначала о печальном – о терминах

ГОСТ 34.003-90 Комплекс стандартов на автоматизированные системы. Термины и определения

Начнем с основного – определения автоматизированной системы (AC) – «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Уже давно в понятие АС включаются системы, полностью автоматизирующие ту или иную деятельность, а термин «ИТ» в единственном числе и вовсе не употребляется.

К тому же современные системы позволяют гибко формировать исполняемые ими функции, поэтому термин «установленные функции» также звучит эклектически. А термин «АСУ», который приведен в качестве одного из видов АС и популярный в 90-х годах прошлого века, уже довольно давно вышел из употребления.

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

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

ГОСТ 34. 601-90 Автоматизированные системы. Стадии создания

Не удержусь и процитирую ГОСТ: «Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям».

Часто ли мы задумываемся именно о необходимости и достаточности производимых работ, о том, чтобы максимально использовать свои и чужие наработки и не изобретать «велосипеды»? То есть делать именно то, что активно продвигают современные стандарты жизненного цикла систем и программных систем, лучшие практики и фреймворки, например TOGAF, под термином «reuse».

Конечно, стадии и этапы создания АС – это классический водопад. Но хочу напомнить, что в 90-х годах не было не только методологий agile (они появились почти через 10 лет), но и ООП – объектно-ориентированного программирования. Однако специалисты научились вполне сносно приспосабливать ГОСТ 34 для «гибких» проектов. Чего только не придумают люди, поставленные в жесткие рамки!

Как переводчик ряда стандартов хочу отметить, что перевод стандартов сложен. Не бывает полного соответствия русских и англоязычных терминов

Практически никто сейчас не делает эскизных проектов, которые и в самом ГОСТе признаны необязательными. Хотя во многих случаях создание прототипов для проверки тех или иных технических решений весьма полезно. Правда, их практически никогда не называют эскизными проектами.

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

К сожалению, организации все чаще отказываются от проведения опытной эксплуатации: иногда по объективным причинам, иногда из-за незнания ГОСТа или в целях экономии ресурсов.

ГОСТ 34. 602-89 Техническое задание на создание автоматизированной системы

И тут не обойдусь без цитаты: «Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений».

Насколько часто при формировании требований к АС мы учитываем современность создаваемой АС и то, не ограничили ли мы сами себя, неправильно сформулировав требования, заложив в них собственное весьма ограниченное представление о том, как она должна выглядеть? Возможно, именно поэтому у топ-менеджеров, вышедших из ИТ-специалистов, настолько редки удачные ИТ-проекты!

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

Важным моментом является требование стандарта, в соответствии с которым согласование ТЗ должны вести совместно Исполнитель и Заказчик. Возможно, если бы к этому пункту относились внимательнее, сократилось количество плохих ТЗ и, соответственно, неуспешных ИТ-проектов.

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

Поскольку область ИТ развивается стремительно, ее терминология также весьма подвижна. И это не просто смена одного термина другим, а изменение подходов к той или иной деятельности, к тому или иному понятию. Поэтому «копи пастом» тут не обойтись.

На этом, пожалуй, оставлю ГОСТ 34 и перейду к международным стандартам в лице ГОСТ Р 12207

ГОСТ Р ИСО/МЭК 12207- 2010 Информационная технология (ИТ). Системная и программная инженерия. Процессы жизненного цикла программных средств

Прежде всего в 12207 четко сформулировано, что «приобретающая сторона должна отправить заявку на поставку продукта или услуги идентифицированным поставщикам». Это утверждение можно трактовать как противоречащее ФЗ 44, ограничивающее конкуренцию при осуществлении закупок.

Стейкхолдеры в разных местах стандарта переведены то как заинтересованные стороны, что является устоявшимся переводом термина, то как правообладатели, как этот термин переводили в конце 90-х. Такой разнобой вызывает недоверие к качеству перевода и совершенно недопустим для стандартов вообще и для государственных стандартов в частности.

Как переводчик и эксперт переводов ряда стандартов хочу отметить, что перевод стандартов необыкновенно сложен. Практически не бывает полного соответствия русских и англоязычных терминов. Поэтому даже при самом блестящем переводе часть смысла теряется. Добросовестные переводчики пытаются и рыбку съесть и косточкой не подавиться.

Лично я при переводе технических текстов те термины и словосочетания, которые не имеют устойчивого русского перевода, перевожу транслитерацией. Считая такое коверканье языка меньшим злом, чем искажение смысла. Но для государственных стандартов такой подход неприемлем.

Какой же выход?

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

Тогда государственные организации, которые (к счастью) привыкли основывать свою деятельность на стандартах, с чистой совестью станут использовать обновленные отечественные стандарты. Ведь прошлые их версии будут заменены новыми и выйдут из употребления. А за ними и бизнес потянется.

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

В начало⇑

 

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №03 (86) 2019г.
Выпуск №03 (86) 2019г. Выпуск №02 (85) 2019г. Выпуск №01 (84) 2019г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика