Рус Eng Cn Перевести страницу на:  
Please select your language to translate the article


You can just close the window to don't translate
Библиотека
ваш профиль

Вернуться к содержанию

Тренды и управление
Правильная ссылка на статью:

Исследование роли научно-технического сопровождения в разработке программных продуктов АСУ

Тиханычев Олег Васильевич

ORCID: 0000-0003-4759-2931

кандидат технических наук

заместитель начальника отдела управления перспективных разработок, ГК "Техносерв"

111395, Россия, г. Москва, ул. Юности, 13

Tikhanychev Oleg Vasilyevich

PhD in Technical Science

Deputy Head of Department in the Office of Advanced Development, Technoserv Group 

111395, Russia, Moscow, Yunosti str., 13

tow65@yandex.ru
Другие публикации этого автора
 

 

DOI:

10.7256/2454-0730.2020.1.31212

Дата направления статьи в редакцию:

30-10-2019


Дата публикации:

23-06-2020


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


Ключевые слова:

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

Abstract: The subject of this research is the process of development of software products for Automated Control Systems of industrial and special designation. The object of this research is the functional responsibilities of the software developers based on their roles in this process. The general scientific methods of analysis and synthesis were applied in studying the peculiarities of the development of software products. Leaning on analysis of the content of technical documentation standards that regulates the software development for automated systems of special designation and determines the content of the process and functions of its participants, the author synthesized the suggestions on clarification of the list of experts engaged in the process and their competences. The problem is articulated regarding the improvement of functional responsibilities of the participants of this process. It is proposed to specify the technical documentation standards, list of involved experts, and their training programs. Execution of such measures should help to bring the process of development of software products for Automated Control Systems in compliance with the current demands.


Keywords:

management automation, application software, software development, normative documents, developer features, software development support, roles of process participants, refinement of functionality, modern development principles, documentation adjustment

Введение

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

В современных условиях успешно используется достаточно много методологий и реализующих их технологий разработки программного обеспечения (ПО): как для жестких «каскадных» (Rapid Application Development, Rational Unified Process, Microsoft Solutions Framework), так и для «гибких» (Extreme Programming, Lean, Scrum, Feature driven development и др.), моделей этого процесса [1-6]. Все эти технологии и модели реализуются целым набором специализированных программных средств управления разработкой: Team Foundation Server, Jira и им подобных [7,8]. С их применением ведётся достаточно эффективная разработка и внедрение коммерческих систем автоматизации управления организациями и процессами: ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) и SCADA (Supervisory Control And Data Acquisition) – систем, их версий, других автоматизированных систем. Для рационального использования возможностей современных технологий разработки ПО в мировой практике разработки сформировалась целая когорта специалистов, каждый из которых отвечает за тот или иной этап разработки.

Но, как показывает анализ отдельных областей разработки ПО, в первую очередь, ПО для автоматизированных систем управления (АСУ) специального назначения, современные подходы в данном процессе используются не всегда. Если в сфере коммерческой разработки их использование налажено, то при разработке ПО систем специального назначения, разработка которых ведётся по Государственному заказу, проблема пока решена не в полном объёме. И дело не только в специальных требованиях по организации работ и поставок в рамках Гособоронзакза и ограничениях на использование зарубежных технологий [9]. Основным препятствием, как представляется, является используемая при этом нормативно-техническая документация, задающая процесс разработки ПО подобных систем, а также определяемый этой документацией перечень привлекаемых специалистов и их компетенции [10-12]. Это делает актуальной проблему уточнения требований по составу и компетенциям специалистов, привлекаемых ко всем этапам разработки ПО для специальных систем автоматизированного управления.

1.Специалисты, участвующие в процессе разработки программного обеспечения

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

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

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

- проблема формализации описания предметной области;

- проблемы формализованного доведения разработчику требований к продукту и описания ожиданий от его внедрения;

- сложность трактовки требований заказчика на разных уровнях разработки ПО;

- отсутствие сплошного объективного контроля процесса разработки, недопустимо высокой степенью дискретности этого контроля и т.п.

Примерами, подтверждающими данный тезис может служить незавершенная разработка общегосударственной автоматизированной системы учёта и обработки информации «ОГАС», а также известные проблемы в разработке автоматизированных систем военного назначения [16,17].

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

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

- заказчик (министерства, автоматизируемые организации);

- разработчик (предприятия промышленности в соответствии с конкурсом на открытие опытно-конструкторской работы (ОКР);

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

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

По этой причине процесс может давать сбои, которые на практике выражаются в том, что:

- затягиваются сроки разработки;

- получившееся в результате работ ПО не всегда соответствует ожиданиям заказчика;

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

Сложившаяся ситуация напоминает уже происходивший в конце 1960-х – начале 1970-х гг. кризис разработки программного обеспечения [21]. И если для сферы разработки прикладных коммерческих программ он был успешно преодолён за счёт развития новых методологий управления процессами, то в разработке промышленного ПО для АСУ его признаки пока присутствуют. При этом, мировой опыт организации разработки ПО используется недостаточно активно. И не потому, что использование методологий и реализующих их систем зарубежной разработки противоречит требованиям информационной безопасности. Вопрос в другом: использование современных подходов подразумевает строгую формализацию процесса, разделение ответственности между его участниками, наличие у них соответствующих компетенций. К сожалению, данные требования не обеспечиваются существующей в нашей стране системой нормативных и руководящих документов по разработке ПО [22,23].

2.Об уточнении требований к участникам процесса разработки программного обеспечения

Возникает вопрос: какой выход возможен из сложившейся ситуации? Вариантов, на взгляд автора, может быть два: либо менять структуру органов управления и научно-технического сопровождения, участвующих в разработке, либо уточнять их функции, распределяя и дополняя их теми, которые соответствуют современным подходам к созданию ПО [24-26].

Наиболее целесообразным представляется реализация второго варианта, не требующего коренного переформатирования системы заказов и разработки ПО.

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

Функциональные обязанности специалистов в соответствии с действующей нормативной документацией могут быть следующими:

- организация-заказчик, иногда разделяемая на финансового и технического заказчика;

- специалисты и организации по научно-техническому сопровождению разработки;

- разные категории специалистов из состава организации-разработчика ПО;

- пользователи ПО в составе эксплуатирующей организации, являющейся, как правило техническим заказчиком (заказчиком «по существу»).

Данные категории могут детализироваться на разных этапах разработки. Например, на этапе информационного обследования и формирования информационной модели объекта автоматизации, в соответствии с требованиями нормативного документа Р 50.1.028-2001 в коллектив, занимающийся проектированием, могут входить следующие участники:

- руководитель проекта;

- разработчики модели;

- технический совет;

- эксперты в предметной области;

- библиотекарь.

Подобная детализация может существовать на любом другом этапе цикла разработки АСУ.

В свою очередь, к ключевым ролям, в соответствии с зарубежным стандартом управления проектами PMBoK (Project Management Body Of Knowledge), принято относить [27]:

- бизнес-аналитик, главная обязанность которого заключается во взаимодействии как с клиентом, так и с командой разработчиков;

- менеджер проекта, основной задачей которого является управление командой разработчиков и координация работ;

- дизайнеры интерфейсов;

- разработчики ПО;

- специалисты по управлению качеством;

- специалисты по маркетингу.

Существуют и другие категории специалистов, например, в области управления знаниями. Является очевидным, что процессы разработки коммерческого ПО для частного использования и программного обеспечения промышленных и специальных АСУ имеют отличия, но в общем виде, относительно конечного результата (разработки ПО, удовлетворяющего требованиям заказчика), процессы схожи. И, учитывая бурное развитие информационных технологий в последние десятилетия и успешный опыт создания CRM и ERP систем, таких, например, как семейство SAP (Systeme, Anwendungen und Produkte in der Datenverarbeitung), у коммерческой области есть чему поучиться. А успешный опыт целесообразно использовать.

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

Вариант такого уточнения, сформулированный автором на основе обобщения опыта работ по разработке ПО АСУ, приведен в таблице 1.

Таблица 1 – Возможный вариант уточнения задач участников процесса разработки ПО АСУ

Участник процесса по существующим руководящим документам

Функции, определяемые существующей нормативной и руководящей документацией

Аналгии по типу специалистов по современным взглядам на разработку коммерческого ПО

Предлагаемые функции участников процесса разработки промышленного ПО АСУ

Заказчик по существу (технический), потенциальный пользователь

1)Выявление задачи

2)Формулировка проблемы

3)Приемка работы и отдельных её этапов

1)Эксперт предметной области

2)Руководитель проекта

3)Корпоративный архитектор (Enterprise-архитектор)

1)Руководство проектом и его отдельными этапами (project management)

2)Управление требованиями (software requirements management)

Финансовый заказчик

1)Задание НИОКР

2)Организация всех этапов выполнения работы

1)Бизнес-менеджер

2)Менеджер по продукту

1)Управление рисками (risk management) 2)Управление продуктами (product management)

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

1)Анализ тенденций предметной области, генерация предложений

2)Подготовка исходных данных для задания ОКР (обычно, в рамках НИР)

3)Подготовка исходных данных на всех этапах выполнения ОКР

4)Организация апробации ПО

5)Участие в приемке работы и её этапов

1)Менеджер проекта

2)Бизнес-аналитик

3)Системный архитектор

4)Дизайнер интерфейсов

5)Математик-алгоритмист

1)Управление ожиданиями (expectations management)

2)Управление качеством (quality management)

3)Управление данными и знаниями (knowledge management)

Предприятие-разработчик

1)Разработка программной продукции

2)Разработка РКД

3)Тестирование

4)Представление продукции на приёмо-сдаточные испытания

1)Программный инженер

2)Программист

3)Технический писатель

4)Тестировщик

1)Разработка программного кода

2)Конфигурационное управление (software configuration management)

3)UNIT и функциональное тестирование

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

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

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

В предлагаемой структуре имеются функции и категории специалистов, которых просто не существует в нашей стране на настоящее время. Например, персонала для реализации концепции управления данными организации Data Governance. Но если признать очевидное, что информация – это ценнейший ресурс любой организации, особенно сопровождающей разработку АСУ, то объективно необходимо наличие специалистов с соответствующими компетенциями (Data Scientists). Компетенциями, аналогичными используемым в ведущих мировых компаниях, работающих с данными: главный специалист (Chief Data Officer), специалист по данным (Data-steward), инженер (Data Engineers) и «владелец» (Data Owners) данных, а также некоторые другие позиции, для определения которых у нас пока нет даже точного перевода. Впрочем, проблема не в точности перевода тех или иных должностей или компетенций, проблема в отсутствии их аналогов в перечне должностей и профессий.

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

3.Предпосылки реализации предлагаемого подхода

Что же можно сделать для реализации предлагаемого в статье подхода?

Нужно не так много – внести поправки в нормативные и руководящие документы и подготовить специалистов необходимого профиля.

Это не слишком сложно, тем более, что аналогичный опыт в нашей стране имеется. Опыт подготовки специалистов класса «системный архитектор» и «системный инженер» имеют многие ВУЗы страны. Наглядный один пример можно найти в оборонно-промышленном комплексе: в своё время, для обеспечения «связки» между промышленностью и военным заказчиком при ряде военных академий была создана система подготовки специалистов уровня «инженер-исследователь». Эти уникальные специалисты имели как войсковой опыт, так и научные знания о методах проведения исследований и организации научной работы [28,29]. Их служба в научно-исследовательских организациях Минобороны показала востребованность подобных кадров и их успешное использование в системе военно-научного сопровождения ОКР по разработке программной продукции. К сожалению, в начале 2000-х годов данную программу свернули. Но наработки и опыт подготовки, наверняка, сохранился. С учётом этого, представляется возможным организовать подготовку недостающих специалистов по разработке ПО по проверенным программам и методикам, дополнив их курсами по методологии и современным технологиям эффективного создания ПО. Остаётся только внести изменения в соответствующую руководящую и нормативную документацию.

Выводы о возможных мерах по реализации предлагаемого подхода

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

- скорректировать нормативную документацию, регламентирующую процесс разработки ПО специальных систем, в первую очередь, ГОСТ серии 34 и РВ 15 [13,14], с целью уточнения этапности этого процесса, перечня его участников и квалификационных требований к ним;

- организовать подготовку по недостающим специальностям в ВУЗах, скорректировать учебные планы, обеспечив выбор соответствующих дисциплин в вариативной компоненте обучения;

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

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

Уточнение перечня привлекаемых к разработке ПО специалистов и требований к ним, наряду с оптимизацией самого процесса [30-33], обеспечит предпосылки для перехода к промышленным методам разработки ПО специальных АСУ, методам, соответствующим мировым тенденциям этого процесса.

Библиография
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.
32.
33.
References
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.
32.
33.

Результаты процедуры рецензирования статьи

В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.

Представленная статья посвящена обзору вопросов организации и нормативного регулирования этапов разработки ПО. Название статьи и положения статьи позволяют предположить, что направление анализа связано с промышленным ПО, возможно в какой-то узкой области. Автор акцентирует внимание на необходимости разработки нормативной документации, отвечающей современным требованиям и имеющимся зарубежным стандартам, что делает работу актуальной. Однако в настоящий момент общее впечатление от статьи – Автор ориентируется в основных процессах разработки ПО, однако не работает в данной области. Формулировки очень общие, размытые, отсутствует конкретные примеры или анализ аналогов. Отсутствует формулировка собственного исследования Автора, что не позволяет оценить научную новизну.
Замечания.
В представленном виде статья носит обзорный характер, формулировки размыты. Приведенные недостатки очень общие. Отсылка к проблемам разработки 80х вызывает сомнение. Если статья содержит обзор тенденций, необходимы ссылки на соответствующие публикации и предметный анализ. Если имеется ввиду конкретная область, необходимо основное внимание уделить именно выбранной области.
Формулировка названия должна быть четкой и соответствовать работе, необходимо её заменить. Напр., добавить исследовательскую компоненту изменить название на «Исследование роли научно-технического ….»
Формулировка «функционал специалистов» некорректна.
Указанные участники разработки ПО в соответствии с PMBoK больше отвечает действительности, чем указанные со ссылкой на нормативные документы. Необходимо подчеркнуть это, привести обоснование.
Таблица 1 оставлена на основе каких данных? Необходимо указать, является ли это личной разработкой Автора.
В разделе «Предложения по реализации» пример с подготовкой специалистов военной академии показателен, но вероятно лучше его привести в начале статьи. Предложения должны содержать конкретный перечень мер.
Из приведенного заключения можно предположить что сейчас сопровождение разработки АСУ не соответствует мировым тенденциям. Однако библиография также не содержит ссылок на зарубежные источники.
Каким образом дополнение списка специальностей повлияет на сопровождение разработки ПО АСУ? Вероятно стоит откорректировать учебные планы, предложив в вариативной компоненте выбор соответствующих дисциплин.
Библиография достаточно, содержит преимущественно публикации за последние 5 лет. Нет ссылок на публикации в зарубежных изданиях, хотя Автор упоминает что зарубежом исследуемые вопросы проработаны на другом уровне.
Стиль изложения материалов статьи научно-популярный. Встречаются синтаксические ошибки.
Статью необходимо переработать, расставив акценты на собственное и исследование и конкретные предложения Автора.

Результаты процедуры повторного рецензирования статьи

В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.

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

Методология исследования основана на теоретическом подходе с применением методов анализа, обобщения, сравнения, синтеза.

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

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

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

Структура рукописи включает следующие разделы: Введение (процесс разработки программной продукции, оптимизация процесса разработки – сокращение сроков, уменьшение количества ошибок, снижение стоимости, методологии и технологии разработки программного обеспечения (ПО) для жестких «каскадных» и «гибких» моделей, специализированные программные средства управления разработкой, разработка и внедрение автоматизированных систем управления (АСУ), ПО для АСУ специального назначения, действующая нормативно-техническая документация, проблема уточнения требований по составу и компетенциям специалистов, привлекаемых ко всем этапам разработки ПО для специальных систем автоматизированного управления), 1. Специалисты, участвующие в процессе разработки программного обеспечения (анализ состояния разработки промышленного ПО, процесс разработки прикладного программного обеспечения для АСУ промышленного и специального назначения, совокупность факторов организационного характера, квалификационные требования к персоналу, ряд объективных и субъективных проблем, научно-техническое сопровождение, привлечение научно-исследовательских организаций при разработке специальных систем типа ERP, CRM, SCADA, перечень специалистов по научно-техническому сопровождению и их функции в соответствии с действующей нормативной документацией, каскадный процесс разработки, его сбои, кризис разработки программного обеспечения, существующая система нормативных и руководящих документов по разработке ПО), 2. Об уточнении требований к участникам процесса разработки программного обеспечения ( «роли» в разработке ПО, перестановки в среде разработчиков ПО АСУ, функциональные обязанности специалистов, требования нормативного документа Р 50.1.028-2001 – руководитель проекта, разработчики модели, технический совет, эксперты в предметной области, библиотекарь, зарубежный стандарт управления проектами PMBoK – бизнес-аналитик, менеджер проекта, дизайнеры интерфейсов, разработчики ПО, специалисты по управлению качеством, специалисты по маркетингу, специалисты в области управления знаниями, предложения по уточнению задач участников процесса разработки, организация научно-технического сопровождения, персонал для реализации концепции управления данными организации Data Governance), 3. Предпосылки реализации предлагаемого подхода (правки в нормативные и руководящие документы, подготовка специалистов необходимого профиля, опыт подготовки специалистов класса «системный архитектор» и «системный инженер», система подготовки специалистов уровня «инженер-исследователь»), Выводы о возможных мерах по реализации предлагаемого подхода (заключение), Библиография.

Содержание в целом соответствует названию. В то же время по содержанию рукописи возникает ряд вопросов. Во-первых, не ясно, почему сформулированные автором рекомендации относятся именно к разработке АСУ, а не программных продуктов в целом. Объяснение различиями в целях (коммерческие и некоммерческие разработки) вряд и можно считать исчерпывающим. Также весьма трудно согласиться с тем, что разработки ПО до сих пор ведутся исключительно по ГОСТам 1980–90 – х гг. – даже если эти документы исполняются, специалисты наверняка используют широко известные более современные алгоритмы и методики. В формулировке заголовка, возможно, следует также уточнить, о каком исследовании научно-технического сопровождения идёт речь. Очевидно, что дело не в названиях должностей либо адекватности их перевода с английского языка. Желательно также привести более широкий спектр аргументов (в том числе эмпирические данные, анализ конкретных ситуаций и т.п.), свидетельствующих о достоверности и надёжности полученных автором результатов.

Библиография включает 31 источник отечественных и зарубежных авторов – монографии, научные статьи, нормативно-технические документы, учебно-методические пособия. Библиографические описания некоторых источников нуждаются в корректировке в соответствии с ГОСТ и требованиями редакции, например:
1. Карпов А. В. Особенности применения современных методов разработки программного обеспечения защищенных автоматизированных систем // Программные продукты и системы. – 2016. – № 1. – C. 5–12.
2. Бахтизин В. В., Неборский С. Н. Разработка программных средств на основе гибких методов // Программные продукты и системы. – 2008. – № 2. – С. 44–47.
3. Glass R. L. Facts and Fallacies of Software Engineering. – Место издания ??? : Addison Wesley, 2002. – 312 p.
4. Black, R. Critical Testing Processes: Plan, Prepare, Perform, Perfect / R. Black. – Addison Wesley, 2003. - 79 p.
5. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis / W. J. Brown, R. C. Malveau, H. W. McCormick et al. – N. Y. : John Wiley. В целом, несмотря на некоторые замечания, статью можно рекомендовать к публикации.