Research of the role of the scientific and technical support in development of software products for Automated Control Systems

Tikhanychev Oleg Vasilyevich ORCID: 0000-0003-4759-2931 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 Other publications by this author

Введение

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

В современных условиях успешно используется достаточно много методологий и реализующих их технологий разработки программного обеспечения (ПО): как для жестких «каскадных» (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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