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

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

показать все 

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

10.12.2018

II Федеральный форум «Smart Cars & Roads

Читать далее 

10.12.2018

Кубок Связи и ИТ

Читать далее 

10.12.2018

Большой Национальный форум информационной безопасности «Инфофорум-2019»

Читать далее 

10.12.2018

Искусственный интеллект сможет предотвратить часть угроз для DNS

Читать далее 

10.12.2018

Бизнес-игры приобретают всё большую популярность в HR-среде

Читать далее 

10.12.2018

Код Перми:ИБ в условиях холодной войны

Читать далее 

10.12.2018

Код Нижнего Новгорода или Как перестать беспокоиться о комплаенсе и начать жить

Читать далее 

показать все 

Статьи

22.11.2018

Все только начинается! Заметки с форума «Открытые инновации – 2018»

Читать далее 

22.11.2018

Роботы vs рекрутеров

Читать далее 

22.11.2018

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

Читать далее 

22.11.2018

Блокчейн после ажиотажа

Читать далее 

22.11.2018

Open Source – здоровье ИТ можно купить

Читать далее 

21.04.2017

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

Читать далее 

16.04.2017

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

Читать далее 

16.04.2017

Цифровизация экономики

Читать далее 

23.03.2017

Сервисная компания – фея или Золушка?

Читать далее 

17.02.2017

Информационные технологии-2017

Читать далее 

показать все 

Устарели ли стандарты ГОСТ 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 и получить качественные актуальные отечественные стандарты внедрения, создания и развития программных систем. При этом не надо забывать о гармонизации их с международными стандартами, что вполне возможно.

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

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

В начало⇑

 

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

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

Выпуск №09 (82) 2018г.
Выпуск №09 (82) 2018г. Выпуск №08 (81) 2018г. Выпуск №07 (80) 2018г. Выпуск №06 (79) 2018г. Выпуск №05 (78) 2018г. Выпуск №04 (77) 2018г. Выпуск №03 (76) 2018г. Выпуск №02 (75) 2018г. Выпуск №01 (74) 2018г.
Вакансии на сайте Jooble

           

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

 

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

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