Программные продукты и системы, 2016, № 1 (113)

Научно-исследовательский институт

«Центрпрограммсистем»

Программные

продукты и системы

МЕЖДУНАРОДНЫЙ НАУЧНО-ПРАКТИЧЕСКИЙ ЖУРНАЛ

№ 1 (113), 2016

Главный редактор

С.В. ЕМЕЛЬЯНОВ, академик РАН

Тверь

PROGRAMMNYE PRODUKTY

I SISTEMY

(SOFTWARE & SYSTEMS)

International research and practice journal

no. 1 (113), 2016

Editor-in-Chief 

S.V. EMELYANOV, Academician of the Russian Academy of Sciences

Tver

Russian Federation

Research Institute CENTERPROGRAMSYSTEM

 ПРОГРАММНЫЕ ПРОДУКТЫ И СИСТЕМЫ

2016, № 1 (113)

Международное научно-практическое 
приложение к международному журналу 
«ПРОБЛЕМЫ ТЕОРИИ И ПРАКТИКИ УПРАВЛЕНИЯ»
Главный редактор 
С.В. ЕМЕЛЬЯНОВ, академик РАН (г. Москва, Россия)

Научные редакторы:
В.П. КУПРИЯНОВ, генеральный директор НИИ «Центрпрограммсистем» 
(г. Тверь, Россия)
Н.А. СЕМЕНОВ, д.т.н., профессор ТвГТУ (г. Тверь, Россия)
В.А. ИЛЬИН, д.в.н., профессор, ВУНЦ ВМФ (г. Санкт-Петербург, Россия)
Рецензенты: 
Н.А. Семенов, д.т.н., профессор ТвГТУ (г. Тверь, Россия)
А.М. Кытманов, д.ф.-м.н., профессор СФУ (г. Красноярск, Россия)
А.П. Афанасьев, д.ф.-м.н., профессор ИППИ РАН (г. Москва, Россия)
В.Н. Вагин, д.т.н., профессор, МАИ (г. Москва, Россия)
А.Б. Баламетов, д.т.н., профессор АзНИПИИЭ (г. Баку, Азербайджан)
Н.В. Меньшутина, д.т.н., профессор РХТУ (г. Москва, Россия)
К.В. Сафонов, к.ф.-м.н., профессор СибГАУ (г. Красноярск, Россия)

Издатель НИИ «Центрпрограммсистем»

(г. Тверь, Россия)

Учредители: МНИИПУ (г. Москва, Россия),
Главная редакция международного журнала 
«Проблемы теории и практики управления»

(г. Москва, Россия),

Закрытое акционерное общество 

«Научно-исследовательский институт 

«Центрпрограммсистем» (г. Тверь, Россия)

Журнал зарегистрирован

в Комитете Российской Федерации

по печати 26 июня 1995 г.

Регистрационное

свидетельство № 013831

Подписной индекс в каталоге

Агентства «Роспечать» 70799

ISSN 0236-235X (печатн.)
ISSN 2311-2735 (онлайн)

МЕЖДУНАРОДНАЯ РЕДАКЦИОННАЯ КОЛЛЕГИЯ

Семенов Н.А. – д.т.н., профессор Тверского государственного технического университета, заместитель главного 
редактора (г. Тверь, Россия)
Решетников В.Н. – д.ф.-м.н., профессор Российского государственного технологического университета 
им. К.Э. Циолковского (МАТИ), заместитель главного редактора (г. Москва, Россия)
Арефьев И.Б. – д.т.н., профессор Морской академии Польши (г. Щецин, Польша)
Афанасьев А.П. – д.ф.-м.н., профессор Московского физико-технического института (технического университета), 
заведующий Центром распределенных вычислений Института проблем передачи информации РАН (г. Москва, Россия)
Батыршин И.З. – д.т.н., профессор Мексиканского института нефти (г. Мехико, Мексика)
Вагин В.Н. – д.т.н., профессор Московского энергетического института (технического университета) 
(г. Москва, Россия)
Голенков В.В. – д.т.н., профессор Белорусского государственного университета информатики и радиоэлектроники
(г. Минск, Беларусь)
Еремеев А.П. – д.т.н., профессор Московского энергетического института (технического университета)
(г. Москва, Россия)
Котов А.С. – кандидат наук, ассистент профессора университета Уэйна (штат Мичиган) (г. Детройт, США)
Кузнецов О.П. – д.т.н., профессор Института проблем управления РАН (г. Москва, Россия)
Курейчик В.М. – д.т.н., профессор Технологического института Южного федерального университета 
(г. Таганрог, Россия)
Лисецкий Ю.М. – к.т.н., генеральный директор «S&T Ukraine» (г. Киев, Украина)
Мамросенко К.А. – к.т.н., доцент Российского государственного технологического университета 
им. К.Э. Циолковского (МАТИ), заведующий отделом Центра визуализации и спутниковых 
информационных технологий ФНЦ НИИСИ РАН (г. Москва, Россия)
Бертран Мейер – доктор наук, профессор, заведующий кафедрой Высшей политехнической школы – ETH (г. Цюрих, Швейцария)
Нгуен Тхань Нги – д.ф.-м.н., профессор, проректор Ханойского открытого университета (г. Ханой, Вьетнам)
Николов Р.В. – доктор наук, профессор Университета библиотековедения и информационных технологий Софии
(г. София, Болгария)
Осипов Г.С. – д.ф.-м.н., профессор, заместитель директора Института системного анализа РАН (г. Москва, Россия)
Палюх Б.В. – д.т.н., профессор Тверского государственного технического университета (г. Тверь, Россия)
Рахманов A.A. – д.т.н., профессор, заместитель генерального директора Концерна «РТИ Системы» (г. Москва, Россия)
Серов В.С. – д.ф.-м.н., профессор Университета прикладных наук Оулу (г. Оулу, Финляндия)
Сотников А.Н. – д.ф.-м.н., профессор, Межведомственный суперкомпьютерный центр РАН (г. Москва, Россия)
Сулейманов Д.Ш. – академик АН Республики Татарстан, д.т.н., профессор Казанского государственного 
технического университета (г. Казань, Республика Татарстан, Россия)
Тарасов В.Б. – к.т.н., доцент Московского государственного технического университета им. Н.Э. Баумана (г. Москва, Россия)
Таратухин В.В. – доктор философии, управляющий директор Европейского исследовательского центра 
в области информационных систем (ERCIS) Вестфальского университета им. Вильгельма (г. Мюнстер, Германия)
Хорошевский В.Ф. – д.т.н., профессор Московского физико-технического института (технического университета) 
(г. Москва, Россия)
Язенин А.В. – д.ф.-м.н., профессор Тверского государственного университета (г. Тверь, Россия)

АССОЦИИРОВАННЫЕ ЧЛЕНЫ РЕДАКЦИИ

Московский энергетический институт (технический университет), г. Москва, Россия
Технологический институт Южного федерального университета, г. Таганрог, Россия
Тверской государственный технический университет, г. Тверь, Россия
Научно-исследовательский институт «Центрпрограммсистем», г. Тверь, Россия

АДРЕС РЕДАКЦИИ
Россия, 170024, г. Тверь, пр. 50 лет Октября, 3а
Телефон (482-2) 39-91-49
Факс (482-2) 39-91-00
E-mail: red@cps.tver.ru
www.swsys.ru

Подписано в печать 25.02.2016 г.

Отпечатано ООО ИПП «Фактор и К»

Россия, 170028, г. Тверь, ул. Лукина, д. 4, стр. 1

Выпускается один раз в квартал. Год издания двадцать девятый

Формат 6084 1/8. Объем 196 стр.

Заказ № 6. Тираж 1000 экз. Цена 257,40 руб.

Автор статьи отвечает за подбор, оригинальность и точность приводимого фактического материала.
Авторские гонорары не выплачиваются. При перепечатке материалов ссылка на журнал обязательна.

 PROGRAMMNYE PRODUKTY I SISTEMY (SOFTWARE & SYSTEMS)

2016, no. 1, DOI: 10.15827/0236-235X.113

International research and practice supplement for International magazine 
THEORETICAL AND PRACTICAL ISSUES OF MANAGEMENT
Editor-in-chief 
S.V. Emelyanov, Academician of the Russian Academy of Sciences (Mosсow, Russian Federation)

Science editors:
V.P. Kupriyanov, Director General, R&D Institute Centerprogramsystem (Tver, Russian Federation)
N.A. Semenov, Dr.Sc. (Engineering), Professor TSTU (Tver, Russian Federation)
V.A. Ilin, Dr.Sc. (Military), Professor Military Institute VUNTS Navy (St. Petersburg, Russian Federation)

Reviewers: 
N.A. Semenov, Dr.Sc. (Engineering), Professor TSTU (Tver, Russian Federation)
A.M. Kytmanov, Dr.Sc. (Physics and Mathematics), Professor SFU (Krasnoyarsk, Russian Federation)
A.P. Afanasiev, Dr.Sc. (Physics and Mathematics), Professor IITP RAS (Moscow, Russian Federation)
B.N. Vagin, Dr.Sc. (Engineering), Professor MPEI (Moscow, Russian Federation)
A.B. Balametov, Dr.Sc. (Engineering), Professor AzSR&DPPEI (Baku, Azerbaijan Republic)
N.V. Menshutina, Dr.Sc. (Engineering), Professor NUCTR (Moscow, Russian Federation)
K.V. Safonov Ph.D. (Physics and Mathematics), Professor SibSAU (Krasnoyarsk, Russian Federation)

Publisher Research Institute 
CENTERPROGRAMSYSTEM 

(Tver, Russian Federation)

The Founders: International Scientific 

and Research Institute 
for Management Issues 

(Moscow, Russian Federation),

the Chief Editorial Board 

of International Magazine Theoretical 
and practical issues of management

(Moscow, Russian Federation),

Research Institute 

CENTERPROGRAMSYSTEM 

(Tver, Russian Federation)
The magazine is on record 

in Russian committee

on press 26th of June 1995

Registration certificate № 013831

ISSN 0236-235X (print)

ISSN 2311-2735 (online)

INTERNATIONAL EDITORIAL BOARD

Semenov N.A. – Dr.Sc. (Engineering), Professor of Tver State Technical University, Deputy Editor-in-Chief
(Tver, Russian Federation)
Reshetnikov V.N. – Dr.Sc. (Physics and Mathematics), Professor of Russian State Technological University (MATI), 
Deputy Editor-in-Chief (Mosсow, Russian Federation)
Arefev I.B. – Dr.Sc. (Engineering), Professor of Poland Szczecin Maritime Academy (Szczecin, Poland)
Afanasiev A.P. – Dr.Sc. (Physics and Mathematics), Professor of Moscow Institute of Physics and Technology, 
Head of Centre for Distributed Computing of Institute for Information Transmission Problems (Moscow, Russian Federation)
Batyrshin I.Z. – Dr.Sc. (Engineering), Professor of Mexican Petroleum Institute (Mexico City, Mexico)
Vagin V.N. – Dr.Sc. (Engineering), Professor of Moscow Power Engineering Institute (Technical University) 
(Mosсow, Russian Federation)
Golenkov V.V. – Dr.Sc. (Engineering), Professor of Belarusian State University of Informatics and Radioelectronics 
(Minsk, Republic of Belarus)
Eremeev A.P. – Dr.Sc. (Engineering), Professor of Moscow Power Engineering Institute (Technical University) 
(Moscow, Russian Federation)
Kotov A.S. – Ph.D. (Computer Science), Assistant Professor, Wayne State University (Detroit, MI, USA)
Kuznetsov O.P. – Dr.Sc. (Engineering), Professor of the Institute of Control Sciences of the Russian Academy of Sciences
(Moscow, Russian Federation)
Kureichik V.M. – Dr.Sc. (Engineering), Professor of Taganrog Technology Institute at Southern Federal University 
(Taganrog, Russian Federation)
Lisetskiy Yu.M. – Ph.D.Tech.Sc., CEO of S&T Ukraine (Kiev, Ukraine)
Mamrosenko K.A. – Ph.D. (Engineering), Associate Professor of Russian State Technological University (MATI), 
Head of Department of Center of Visualization and Satellite Information Technologies SRISA RAS (Moscow, Russian 
Federation)
Bertrand Meyer – Dr.Sc., Professor, Head of Department in Swiss Federal Institute of Technology in Zurich, ETH (Zurich, 
Switzerland)
Nguyen Thanh Nghi – Dr.Sc. (Physics and Mathematics), Professor, Vice-Principal of Hanoi Open University (Hanoi, Vietnam)
Nikolov R.V. – Full Professor of the University of Library Studies and Information Technology (Sofia, Bulgaria)
Osipov G.S. – Dr.Sc. (Physics and Mathematics), Professor, Deputy of the Principal of Institute of Systems Analysis 
of the Russian Academy of Sciences (Mosсow, Russian Federation)
Palyukh B.V. – Dr.Sc. (Engineering), Professor of Tver State Technical University (Tver, Russian Federation)
Rakhmanov A.A. – Dr.Sc. (Engineering), Professor, Deputy of the CEO of Concern RTI Systems
(Mosсow, Russian Federation)
Serov V.S. – Dr.Sc. (Physics and Mathematics), Professor of the Oulu University of Applied Sciences (Oulu, Finland)
Sotnikov A.N. – Dr.Sc. (Physics and Mathematics), Professor, Joint Supercomputer Center of the Russian Academy 
of Sciences (Moscow, Russian Federation)
Suleimanov D.Sh. – Academician of TAS, Dr.Sc. (Engineering), Professor of Kazan State Technical University
(Kazan, Republic of Tatarstan, Russian Federation)
Tarassov V.B. – Ph.D. (Engineering), Associate Professor of Bauman Moscow State Technical University
(Mosсow, Russian Federation)
Taratoukhine V.V. – Ph.D. (Engineering), Dr.Ph., Managing Director of the Competence Centre ERP and ERCIS Lab
Russia of the ERCIS (Muenster, Germany)
Khoroshevsky V.F. – Dr.Sc. (Engineering), Professor of Moscow Institute of Physics and Technology
(Moscow, Russian Federation)
Yazenin A.V. – Dr.Sc. (Physics and Mathematics), Professor of Tver State University (Tver, Russian Federation)

ASSOCIATED EDITORIAL BOARD MEMBERS

Moscow Power Engineering Institute (Technical University), Moscow, Russian Federation
Technology Institute at Southern Federal University, Taganrog, Russian Federation
Tver State Technical University, Tver, Russian Federation
Research Institute CENTERPROGRAMSYSTEM, Tver, Russian Federation

EDITORIAL OFFICE ADDRESS
50 let Oktyabrya Ave. 3а, Tver, 170024, Russian Federation
Phone: (482-2) 39-91-49  Fax: (482-2) 39-91-00
E-mail: red@cps.tver.ru
www.swsys.ru

Passed for printing 25.02.2016

Printed in printing-office “Faktor i K”

Lukina St. 4/1, Tver, 170028, Russian Federation

Published quarterly. 29th year of publication

Format 6084 1/8. Circulation 1000 copies

Prod. order № 6. Wordage 196 pages. Price 257,40 rub.

Вниманию авторов!

Международный журнал «Программные продукты и системы» публикует материалы научного и научно-практиче
ского характера по новым информационным технологиям, результаты академических и отраслевых исследований в 
области использования средств вычислительной техники. Практикуются выпуски тематических номеров по искусственному интеллекту, системам автоматизированного проектирования, по технологиям разработки программных 
средств и системам защиты, а также специализированные выпуски, посвященные научным исследованиям и разработкам отдельных вузов, НИИ, научных организаций. 

Решением Президиума Высшей аттестационной комиссии (ВАК) Министерства образования и науки РФ междуна
родный журнал «Программные продукты и системы» внесен в Перечень ведущих рецензируемых научных журналов 
и изданий, в которых должны быть опубликованы основные научные результаты диссертаций на соискание ученых 
степеней кандидата и доктора наук.

Информация об опубликованных статьях по установленной форме регулярно предоставляется в систему Россий
ского индекса научного цитирования (РИНЦ), в CrossRef и готовится для передачи в международные базы цитирования.

Условия публикации

К рассмотрению принимаются ранее нигде не опубликованные материалы, соответствующие тематике жур
нала (специализация 05.13.ХХ – Информатика, вычислительная техника и управление) и отвечающие редакционным требованиям.

Работа представляется в электронном виде в формате Word. При обилии сложных формул обязательно нали
чие статьи и в формате PDF. Формулы должны быть набраны в редакторе формул Word (Microsoft Equation или 
MathType). Объем статьи вместе с иллюстрациями – не менее 10 000 знаков. Диаграммы, схемы, графики должны 
быть доступными для редактирования (Word, Visio, Exel). Все иллюстрации для полиграфического воспроизведения представляются в черно-белом варианте. Цветные, тонированные, отсканированные, не подлежащие 
редактированию средствами Word рисунки и экранные формы следует присылать в хорошем качестве для их дополнительного размещения на сайте журнала в макете статьи с доступом по ссылке. (Публикация материалов с 
использованием гипертекста, графики, аудио-, видео-, программных средств и др. возможна в электронном издании 
«Программные продукты, системы и алгоритмы», сайт www.swsys-web.ru.) Заголовок должен быть информативным; сокращения, а также терминологию узкой тематики желательно в нем не использовать. Количество авторов 
на одну статью – не более 4, количество статей одного автора в номере, включая соавторство, – не более 2. Список 
литературы (оформленный в соответствии с ГОСТ Р 7.05–2008), наличие которого обязательно, должен включать 
не менее 10 пунктов.

Необходимы также аннотация (не менее 200 слов), ключевые слова (7–10) и индекс УДК. Название статьи, 

аннотация и ключевые слова должны быть переведены на английский язык (машинный перевод недопустим), а 
фамилии авторов, названия и юридические адреса организаций (если нет официального перевода), пристатейные 
списки литературы – транслитерированы по стандарту BGN/PCGN. 

Вместе со статьей следует прислать отзыв-рекомендацию в произвольной форме, экспертное заключение, 

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

Порядок рецензирования

Все статьи, поступающие в редакцию (соответствующие тематике и оформленные согласно требованиям к 

публикации), подлежат обязательному рецензированию в течение месяца с момента поступления. 

В редакции есть устоявшийся коллектив рецензентов, среди которых члены международной редколлегии 

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

Рецензирование проводится конфиденциально. Автору статьи предоставляется возможность ознакомиться с 

текстом рецензии. При необходимости статья отправляется на доработку.

Рецензии обсуждаются на заседаниях рабочей группы, состоящей из членов научного совета журнала. Засе
дания проводятся раз в месяц в НИИ «Центрпрограммсистем» (г. Тверь), где принимается решение о целесообразности публикации статьи.

Статьи, одобренные редакционным советом, публикуются бесплатно в течение года с момента одобрения, а 

отправленные на доработку – с момента поступления после устранения замечаний.

Редакция международного журнала «Программные продукты и системы» в своей работе руководствуется 

сводом правил Кодекса этики научных публикаций, разработанным и утвержденным Комитетом по этике научных 
публикаций.

Программные продукты и системы / Software & Systems
№ 1 (113), 2016

5

УДК 004.413
Дата подачи статьи: 25.12.15

DOI: 10.15827/0236-235X.113.005-012

ОСОБЕННОСТИ ПРИМЕНЕНИЯ СОВРЕМЕННЫХ МЕТОДОВ 

РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 

ЗАЩИЩЕННЫХ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

В.В. Карпов, к.т.н., первый зам. генерального директора, karpov@cps.tver.ru;

А.В. Карпов, к.т.н., зав. отделением, karpovav@cps.tver.ru

(НИИ «Центрпрограммсистем», просп. 50 лет Октября, 3а, г. Тверь, 170024, Россия)

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

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

Ключевые слова: гибкие методы, гибридный метод, agile, Scrum, разработка ПО.

Одним 
из 
основных 
научно-технических 

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

Разработка автоматизированных систем выпол
няется, как правило, в виде опытно-конструкторских работ (ОКР) и регламентируется в основном 
ГОСТами 34-й серии и РВ 15.203-2001. Эти стандарты определяют перечень этапов ОКР, последовательность и порядок их выполнения, формы отчетных документов и т.п. Необходимо отметить, 
что приведенные ГОСТы в части, касающейся разработки ПО, являются весьма устаревшими.

Действительно, за десятилетия, прошедшие с 

даты ввода их в действие, технология разработки 
ПО ушла далеко вперед. Так, классическая каскадная модель разработки ПО в последнее время 
признана неэффективной из-за недостаточной гибкости в угоду формальному управлению разработкой [1]. Недостаточная гибкость процесса разработки обусловливает неспособность реагировать 
на изменения требований к системе и может в конечном итоге привести к невыполнению технического задания (ТЗ). В связи с этим возникает про
тиворечие между технологическим уровнем разработки современных АСУ и устаревшими требованиями руководящих документов.

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

Гибкие (agile) методы активно применяются в 

области разработки ПО в последние несколько лет. 
Они позволяют устранить ряд недостатков классического каскадного метода (метода водопада), заключающихся в недостаточной гибкости и формальном управлении проектами в ущерб срокам, 
стоимости и качеству. Недостаточная гибкость 
процесса разработки обусловливает неспособность 
реагировать на возникающие изменения требований к системе и может в конечном итоге привести 
к превышению бюджета, срыву сроков и невостребованности продукта. Причинами таких изменений 
могут быть корректировка требований по результатам демонстрации ПО заказчику, конечным пользователям или экспертам в автоматизируемой 

Программные продукты и системы / Software & Systems
№ 1 (113), 2016

6

предметной области, ошибки, допущенные при 
формулировании требований ранее, изменения в 
самой предметной области и т.д. Ряд зарубежных 
авторов [2–4] отмечают, что изменения функциональных требований к ПО в общем случае практически неизбежны и являются частью объективной 
реальности, с которой следует не бороться, препятствуя появлению изменений, а наоборот, приветствовать их даже на завершающих стадиях проекта, потому как скорректированные требования 
являются важнейшим условием создания действительно востребованного изделия, удовлетворяющего актуальные потребности заказчика. Принятие 
изменений требований даже в конце разработки является одним из принципов гибкой методологии, 
определенных в Agile Manifesto [5].

Внедрение гибких методов разработки ПО 

обеспечивает постепенную итерационную реализацию проекта с постоянной обратной связью от конечного пользователя. Проект развивается небольшими итерациями, в рамках каждой из которых в 
общем случае реализуется относительно небольшое приращение функционала системы, представляющее ценность для пользователя. Каждая итерация заканчивается выпуском новой версии ПО, 
которая демонстрируется пользователю (заказчику) с целью получения обратной связи. Объем 
программного кода, разработанного в рамках очередной итерации, оказывается относительно небольшим, что обеспечивает возможность его корректировки в рамках текущего проекта в случае вероятных изменений функциональных требований. 
В результате необходимые изменения вносятся в 
программный код своевременно.

Однако при управлении объемными проектами 

формализация имеет большую ценность, так как 
обеспечивает прозрачность процесса разработки. 
Известный американский стандарт по управлению 
требованиями 
Project
Management
Body
of

Knowledge (PMBOK) в своей третьей версии формально закреплял только методику каскадной модели, а в 2009 г. Институт управления проектами 
(Project Management Institute, PMI) предложил гибридную методологию, позволяющую сочетать достоинства классического метода водопада и современных гибких методов разработки.

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

Внедрение гибких методов в разработку ПО яв
ляется комплексной и достаточно трудоемкой задачей. Она связана с изменением основных технологических и организационных процессов разработки ПО, способа взаимодействия с заказчиком, 
планирования и контроля разработки и т.д. Итерационная разработка задает новый ритм работы не 
только коллективу разработчиков, но и другим отделам организации и даже ее руководству. Нередко 

для внедрения гибких методов разработки в организацию приглашаются сертифицированные и дорогостоящие специалисты.

В НИИ «Центрпрограммсистем» при выполне
нии ряда ОКР была предпринята попытка использовать гибкие методы в рамках действующих нормативных документов и государственных стандартов разработки систем специального назначения. 

Из известных гибких методов был выбран 

Scrum [6]. Следование его основным принципам 
позволяет предоставлять конечному пользователю 
(заказчику) работающее ПО с новыми возможностями в фиксированные и относительно короткие 
итерации, называемые спринтами (sprints). При 
этом сбор требований, проектирование, разработка 
ПО и его демонстрация заказчику могут выполняться в каждом спринте. Однако в соответствии с 
ГОСТ РВ 15.203-2001 этапы ОКР в общем случае 
выполняются последовательно: этапу разработки 
рабочей конструкторской документации предшествуют этапы эскизного и технического проектирования, корректировка опытного образца выполняется после испытаний и т.д. Этапы выполнения 
ОКР зачастую длятся месяцами и даже годами. 
Кроме того, эффективная итерационная разработка 
ПО требует постоянного вовлечения экспертов в 
автоматизируемой предметной области в процесс 
разработки, а не только в моменты сдачи этапов, 
защиты эскизного и технического проектов и т.д. 
В связи с этим целесообразно сформировать 
группу экспертов в предметной области для обеспечения сбора требований, получения обратной 
связи и выполнения ряда других работ в рамках 
ОКР. Например, при разработке автоматизированных систем и программных комплексов военного 
назначения в группу экспертов могут войти должностные лица органов военного управления и специалисты организаций, выполняющих военнонаучное сопровождение.

Важными аспектами внедрения гибких методов 

являются сбор и управление требованиями. Гибкая 
методология разработки ориентируется на динамическое формирование требований. Это дает заказчику право и возможность по результатам очередной итерации формулировать новые требования. 
Однако такой порядок формирования требований 
может привести к тому, что вновь сформированные 
требования будут противоречить уже реализованным и в некоторых случаях требовать решений, 
нарушающих архитектуру разработанного ранее 
ПО. Кроме того, динамическое формирование требований усложняет процесс управления ими, снижает предсказуемость процесса разработки и затрудняет планирование работы. Динамическое 
формирование требований может означать изменение объема работы, сроков проекта или его стоимости. Однако ОКР, как правило, выполняются по заранее согласованному и утвержденному ТЗ, а 
сроки и стоимость работы зачастую жестко опреде

Программные продукты и системы / Software & Systems
№ 1 (113), 2016

7

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

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

Одним из современных подходов к формирова
нию функциональных требований является разработка вариантов использования (прецедентов) [2]. 
Варианты использования утверждают поведение 
системы при обработке запросов пользователя 
(основного действующего лица) и в общем случае 
являются простыми текстовыми описаниями последовательности взаимодействия пользователя с 
системой. При необходимости в описание функциональных требований можно добавить диаграммы 
на формальных языках типа UML, BPMN, IDEF и 
других, поясняющие схемы, рисунки и прочие материалы. Однако, как показывает практика и отмечают некоторые авторы изданий на тему гибкой 
методологии и современных методов формирования требований [2], наибольшую ценность представляют именно текстовые описания прецедентов. 
Разработанные варианты использования целесообразно включить в соответствующие постановки задач в раздел «Порядок решения задачи». При необходимости следует изменить способ нумерации 
расширений описаний прецедентов. Классическим 
способом нумерации расширений является добавление к порядковому номеру расширяемого шага 
основного сценария прецедента литер «а», «б», «в» 
(a, b, c) и т.д. Например, основной сценарий прецедента содержит действие «3. Система выводит документ на печать». Поведение системы в случае 
сбоя печати описывается в расширениях прецедента, например: «3а. В принтере нет бумаги – система предлагает добавить бумагу в лоток и повторить попытку печати». Такой способ нумерации 
расширений прецедентов, приведенных в постановках задач, зачастую является непривычным для 
экспертов в предметной области и может быть заменен на более естественную формулировку в повествовательном стиле.

Трудоемкость разработки, последующего со
гласования и утверждения постановок задач кардинально сокращается в случае применения гибких 
методов разработки ПО. 

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

В случае итерационного подхода актуальность 

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

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

Учитывая это, представляется целесообразной 

реализация дополнительного инструмента, позволяющего отслеживать соответствие реализуемых 
функциональных требований (прецедентов) формальным задачам, сформулированным в ТЗ. Это 
обеспечит трассировку требований и их непротиворечивость. 

Как показала практика, таким инструментом 

может быть простая таблица, содержащая два 
столбца: в одном указываются задачи ТЗ, в другом 
– соответствующие им прецеденты (табл. 1). Она
может быть дополнена столбцом с указанием 

Программные продукты и системы / Software & Systems
№ 1 (113), 2016

8

названия соответствующей постановки или постановок задач. 

Таблица 1

Простой вариант таблицы трассировки 

функциональных требований

Table 1

An easy case of a functional specification trace table

Номер

задачи ТЗ

Номер

постановки задачи
Прецеденты

1
1.1, 1.2
1, 2, 5

2
2.1, 2.2
2, 3, 4

…
…
…

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

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

Значительно упростить процесс разработки 

функциональных требований, повысить их организацию и обеспечить соответствие формальным задачам ТЗ позволяет формирование карт воздей
ствий (Impact Mapping) [7] и карт историй (story
mapping) [8].

Impact Mapping рассматривает функциональ
ные требования в контексте бизнес-целей и делает 
акцент на тех изменениях деятельности конечных 
пользователей, которые должна обеспечить система для их достижения. Фрагмент упрощенной 
карты воздействий приведен на рисунке.

Как видно из рисунка, основной целью автома
тизации является обеспечение оперативности формирования и представления сведений по движению 
пациентов в медицинских организациях. Эта цель 
может быть достигнута изменением деятельности 
двух специалистов: специалиста медицинского 
управления и специалиста медицинской организации. Изменение деятельности первого заключается 
в повышении оперативности сбора данных и расчетов по движению пациентов в подчиненных медицинских организациях, а также в обеспечении автоматизированного контроля получаемых данных. 
Повышение оперативности сбора данных и расчетов может быть обеспечено за счет автоматизированного сбора данных от подчиненных медицинских организаций и автоматизации расчета динамики движения пациентов. Аналогичным образом 
можно интерпретировать всю карту воздействий.

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

Другим хорошо зарекомендовавшим себя на 

практике подходом к формированию функциональных требований является составление карты 

Обеспечить оперативность формирования 
и представление сведений по движению 
пациентов в медицинских организациях

Специалист
медицинского
управления

Специалист
медицинской
организации

Повысить оперативность 
сбора  и расчетов 
по движению пациентов 
в подчиненных 
медицинских 
организациях

Обеспечить 
автоматизированный 
контроль данных 
от подчиненных 
медицинских 
организаций

Повысить оперативность 
представления сведений 
о движении пациентов

Сбор данных от подчиненных 
медицинских организаций

Расчет динамики движения 
пациентов в медицинских 
организациях

Формирование шаблонов сводок 
для подчиненных медицинских 
организаций

Валидация принимаемых сводок

Контроль приема сводок

Заполнение сводок

Суточный учет пациентов

Фрагмент схемы, разработанной с использованием Impact Mapping

A fragment of an Impact Mapping scheme

Программные продукты и системы / Software & Systems
№ 1 (113), 2016

9

историй (story map). Такой подход позволяет в простой табличной форме представить сценарий применения системы и отобразить в нем место функциональных требований в виде вариантов использования или прецедентов (табл. 2).

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

Следующими важными аспектами разработки 

ПО специального назначения являются планирование и отслеживание выполнения работы. Одним из 
недостатков гибких методов является недостаточная формализация планирования, снижающая 
предсказуемость выполнения проекта, в то время 
как действующие стандарты выполнения ОКР, 
напротив, предписывают разрабатывать планирующие документы, например, единый сквозной 
план создания изделия, сетевой план-график и т.д. 

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

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

При планировании работ следует учитывать, 

что сбор требований и проектирование их реализации в общем случае должны опережать разработку 
соответствующего ПО. Это позволяет избежать 
простоев в работе программистов. Целесообразная 
длительность такого опережения составляет однудве итерации [3] (табл. 3).

С целью поддержки планирования разработки 

ПО специального назначения, помимо формальных планирующих документов, предусмотренных 
действующими государственными стандартами, 
может быть применен адаптированный вариант 
бэклога проекта, предусмотренного методом Scrum
(табл. 4). 

В первом столбце таблицы указываются функ
циональные требования. Их приоритет оценивается в баллах от одного до трех и указывается во 
втором столбце. Сложность реализации каждого 

Таблица 2

Упрощенный пример карты историй

Table 2

A simplified example of of a strory map

Расчет сведений по движению пациентов в медицинских организациях

Специалист 

медицинской организации

Специалист 

медицинского управления

Сценарий применения системы:

выполняю суточный учет 
движения пациентов

формирую 
сводку по 
движению 
пациентов

высылаю сводку 
в медицинское 
управление

принимаю сводки 
от медицинских 
организаций

выполняю расчет 
динамики движения 
пациентов 
в медицинских 
организациях и т.д.

Скелет системы:

учет пациентов только 
с ОРВИ

только с 
ОРВИ

в виде файла на 
отчуждаемом носителе

по одной, с отчуждаемого 
носителя

расчет показателя 1

…и с пневмонией
…и с пневмонией

При помощи системы 
обмена электронными 
сообщениями

Сразу нескольких, 
с отчуждаемого 
носителя

расчет показателя 2

…и с ожогами
…и с ожогами

Из системы обмена электронными сообщениями

и т.д.

Программные продукты и системы / Software & Systems
№ 1 (113), 2016

10

функционального требования оценивается аналогично и указывается в третьем столбце таблицы. 
Далее приводится ссылка на прототип графического интерфейса, разработанного дизайнером 
(проектировщиком). Знак «+» в пятом столбце 
означает наличие приемочных тестов, подготовленных группой тестировщиков. Столбец «Результат тестирования» позволяет уяснить наличие и общий характер выявленных дефектов (ошибок). 
Например, условное обозначение «Ф(Р)», закрашенное красным цветом, означает, что ошибки 
были выявлены при проведении приемочных тестов вручную, а «Ф(А)» – при выполнении автоматического приемочного тестирования. Кроме того, 
в этом столбце можно указывать и другие условные 
обозначения результатов тестирования, по тем или 

иным причинам представляющие интерес для руководителя проекта.

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

Приведенная реализация бэклога проекта не 

просто содержит перечень функциональных требований, но и позволяет планировать их выполнение
и отслеживать результаты. Бэклог проекта обоб
Таблица 3

Деятельность аналитиков и проектировщиков опережает работу программистов на одну-две итерации

Table 3

Analysts’ and design engineers’ activity outpaces programmers’ activity by one or two iterations

Роль
Итерация 1
Итерация 2
Итерация 3
Итерация Z

Аналитик
Сбор требований и данных 
от заказчика для итерации 3

Сбор требований и данных 
от заказчика для итерации 4

Сбор требований 
и данных от заказчика 
для итерации 5

…

Проектировщик Проектирование реализации 

требований для итерации 2

Проектирование реализации 
требований для итерации 3

Проектирование 
реализации требований 
для итерации 4

…

Программист
Реализация требований 
итерации 1

Реализация требований 
итерации 2

Реализация требований 
итерации 3

…

Таблица 4

Адаптированный бэклог проекта

Table 4

An adapted project backlog

Функциональное требование 

(прецедент)

Приоритет

(1–3)

Сложность
(1–3)

Наличие прототипа и ссылка 

на него

Готовность 
к тестиро
ванию

Наличие 
приемочного теста

Результат

тестирования

Примечание

Итерация 1 
(дата начала –
дата окончания)
Версия 0.1
Требование 1.1
1
1
…
+
+
Ф(Р)
Группа разработчиков | Тестировщик

Требование 2.3
1
1
…
+
+
Ф(Р) | Ф(А)

Требование 4.3
2
2
…
+
+
Ф(Р)

Требование 4.5
3
5
…
+
+
Ф(Р)

Итерация 2 
(дата начала –
дата окончания)
Версия 0.2
Требование 1.2
1
1
…
+
+
Ф(Р)
Группа разработчиков | Тестировщик

Требование 2.2
2
3
…
+
+
Ф(Р) | Ф(А)

Требование 2.4
3
4
…
+
+
КВ

Требование 3.1
3
5
…
+
+
КВ

Требования, 
не вошедшие 
в итерации