декабрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
						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

показать все 

29.11.2024

Сайберус создает новую ИБ-компанию на основе технологий и экспертизы F.A.C.C.T.

Читать далее 

29.11.2024

ГК InfoWatch представила новую версию InfoWatch ARMA Стена (NGFW) 4.4.

Читать далее 

29.11.2024

ARinteg про архиватор ARZip: что изменилось в функционале и интерфейсе?

Читать далее 

29.11.2024

Avanpost представляет бесплатную и промышленную версии службы каталогов Avanpost DS

Читать далее 

29.11.2024

Новая версия «Блокхост-Сеть 4»: решение для импортозамещения

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В начало⇑

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

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