Agile-модель НИОКР в области компьютерного моделирования систем цифровой обработки сигналов

«Под методом я понимаю точные и простые правила, строгое следование которым ... без лишней траты умственных сил, но постепенно и непрерывно увеличивая знания, способствует тому, что ум достигает истинного познания всего, что ему доступно...»

Р. Декарт (1637)

Введение

В 2017-2018 годах, по мнению авторов отчета Superjob, многие российские компании начнут внедрять различные средства автоматизации, которые позволят избавляться от сотрудников низкой квалификации, заменяя их роботами. К 2018 г. это приведет к падению числа вакансий в разных сферах. а уже с 2018 г. ожидается начало сокращения предложений для сотрудников низкой квалификации на 5 % каждый год. Теми же темпами будет расти и реальная безработица. К 2022 г. уровень безработицы в России может вырасти до 20–25 %.ꜜ Данный прогноз является, скорее всего, слишком «оптимистичным», тем не менее он описывает один из сопутствующих социальных трендов технологического развития, который, если не принять соответствующих мер, может оказаться угрозой для инновационной экономики.

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

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

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

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

4. В новое время (XVII-XX века) бурное развитие науки и техники существенно расширило возможности физических измерений, что предоставило возможность ввести унифицированные системы единиц физических величин, например, МКГСС (середина XIX века) или Международную систему единиц (СИ), принятую в 1960 году. Унификация физических величин (мер) позволила специалистам различных стран взаимодействовать (т. е. обмениваться результатами научных исследований и разработок, т. е. интеллектуальными ценностями) между собой. В настоящее время данная тенденция проявляется в виде разработки и использования различных государственных и международных стандартов. В качестве примера приведем стандарт определения наборов бит «Unicode», в котором определяются наборы кодов символов, которые представляют письменные языки и другие специализированные нотации, например, фонетику звуков речи языка или Emoji-смайлов.

5. В XVI-XX веках развитие науки и техники было обусловлено развитием образования/университетов (в интеллектуальном плане) и книгопечатания/типографий (в информационном плане). Переход от обмена научными сообщениями в форме писем между великими учеными к публикациям в научно-технических журналах представлял «бумажную информатизацию» того времени. Одновременно шел процесс конверсии денежной массы с «презренного металла» на бумажный носитель. В настоящее время процесс информатизации в техническом плане означает переход к электронной форме представления и обеспечения доступа к информации, а в «интеллектуальном» плане – это унификация (переход к гипертекстовой форме или «гипердокументации») и оптимизация (гармонизация/фрактализация) структуры огромных массивов информации. Одновременно идет процесс перевода денежной массы с бумажного носителя в электронную форму. Можно сказать, что деньги являются специфическим типом информационного крипто-продукта, который формально представляет унифицированную юридическую гарантию обеспечения ценностями со стороны источника эмиссии, например, государства или экономического союза.

В «Лаборатории Касперского» главный финансовый вызов в 2017 году связывают с криптовалютами. В компании отмечают, что за последние несколько лет в этой области произошли грандиозные изменения: если раньше на рынке существовал лишь один биткойн, то сегодня число различных криптовалют доходит до полусотни, при этом около десяти из них имеют серьезную рыночную капитализацию. Государства уже смирились с неизбежностью виртуальных денег и постепенно начинают внедрять их в свои финансовые системы.

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

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

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

В работах [1, 2] (Chichagov, 2016; Chichagov, 2016) были рассмотрены концептуальные или гибкие (в отличие от «жестких» реализаций или низкоуровневых спецификаций) информационно-аналитические модели хаордических/организационных систем различного масштаба. В настоящей работе с позиции системного подхода рассматривается модель организации НИОКР или иначе процесса разработки компьютерных/имитационных моделей систем с акцентом на конкретную область знаний «Цифровая обработка сигналов» (ЦОС).

Процесс разработки компьютерных/имитационных моделей систем ЦОС, как, впрочем, и других ИТ-продуктов представляет долговременный комплексный процесс, в котором участвуют множество заинтересованных лиц, включая специалистов различных направлений деятельности. Следует также отметить, что область знаний «информационная технология» (ИТ) за последние 50 лет сильно разрослась и ее стало довольно трудно определить и изложить в рамках одного университетского курса. В связи с этим организацией ACM было принято решение о ее структуризации (специализации), т. е. разделении на «компоненты» или четыре основные дисциплины: информатика (computer science), программная инженерия (software engineering), проектирование аппаратных платформ (hardware engineering) и информационные системы (information systems). Рекомендации по составу и преподаванию этих дисциплин были выпущены в начале XXI века.

Программная инженерия, в соответствии со стандартом ACM and IEEE «Software Engineering Curricula 2004» [3, 4], включает в себя следующие области знаний и практики:

– основы компьютинга (основы информатики, технологии и средства разработки, формальные методы);

– основы математики и инженерии (в том числе инженерная экономика ПО);

– профессиональная практика (работа в команде, навыки коммуникации, этика);

– основы моделирования (анализ, работа с требованиями, спецификации);

– проектирование ПО (концепции и стратегии проектирования, проектирование человеко-машинного интерфейса, средства поддержки проектирования);

– верификация и аттестация ПО (основы, рецензия кода, тестирование, оценка пользовательского интерфейса, анализ проблем);

– эволюция (модификация/сопровождение) ПО;

– процессы разработки ПО;

– качество ПО (стандарты качества ПО, процессы обеспечения качества ПО, процесса, продукта);

– управление программными проектами (концепции менеджмента, планирование и отслеживание выполнения проектов, управление персоналом, управление конфигурацией ПО).

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

Обзор процессов разработки ПО

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

Движущей силой проекта является «команда» (рис. 1), т. е. группа специалистов – разработчиков системы (изделия/произведения/продукта). Важным компонентом проекта также является выбор «технологии разработки», которая описывает методологию типового процесса выбранного направления деятельности и инструментарий разработчиков системы. Хорошо известной составляющей проекта является проектная документация, которая отражает ход развития проекта и представляет «ноу-хау» команды проекта.

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

Для управления процессом разработки ПО используются различные методологии, среди которых можно отметить OKR (Objectives and Key Results – цели и ключевые результаты) [5], разработанную в корпорации «Intel»; PMBoK (Project Management Body of Knowledge, свод профессиональных знаний по управлению проектами института PМI) [6]; гибкую методологию разработки «Scrum» [7, 8] (Kon, 2015; (Kniberg, 2015) и др. В частности, суть методологии «Scrum» можно кратко сформулировать в трех предложениях.

Рис. 1. Сакраментальная команда проекта ПО (составлено автором)

Первое – командная работа. Существует всего три роли: заказчик и владелец продукта, знающий, что он хочет; самоорганизующийся коллектив специалистов, принимающий решения и отвечающий за них и «администратор» проекта (Scrum-мастер), который обеспечивает и координирует работу, помогая команде развивать проект в заданном темпе.

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

И третье – методология «Scrum» является очень простой в организационном плане. В обычном проекте часто используется планирование с процентами исполнения. Однако что означает задача, выполненная на 32 %? В «Scrum» все просто: если задача протестирована и принята заказчиком – значит, она выполнена. Задача, не протестированная и не принятая заказчиком, не выполнена. Каждый раз в «начале недели» команда проекта собирается на совещание и обсуждает, что было сделано и что нужно будет сделать «за неделю». В итоге есть общее понимание того, в каком состоянии находится проект.

В проектах разработки программного обеспечения методология «Scrum» хорошо сочетается с принципами и методиками гибкого моделирования («Agile Modeling»), в частности, с технологией экстремального программирования «ХР». Следует заметить, однако, что технология «ХР» описывает процесс разработки с позиции программиста (научно-технический аспект), тогда как методология «Scrum» делает акцент на описание процесса разработки со стороны администратора или менеджера проекта (организационно-управленческий аспект).

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

Методология процесса разработки ПО достаточно хорошо известна и содержит следующие виды работ: анализ проблемы и формулировку технического задания (ТЗ), конструирование (проектирование) системы, реализацию (кодирование), испытание (тестирование) и документирование программной системы/изделия. Если указанные виды работ выполняются «полностью» последовательно, то их обычно называют этапами, а соответствующая методика разработки носит название каскадной или «водопадной» модели процесса разработки ПО. Эта модель описывает последовательный «процесс без возвращений» к пройденным этапам. Основная слабость указанной модели – сложный процесс исправления ошибок, которые разработчики ПО допускают на ранних этапах, а обнаруживают на более поздних этапах процесса разработки. В настоящее время данная модель разработки ПО практически не используется, но имеет важное учебно-методическое значение.

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

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

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

Документацию проекта ИТП обычно разделяют на «концептуальную», «логическую» и «физическую» составляющие проекта. В «концептуальном проекте» приводится описание модели обработки данных и интерпретация функций системы со стороны предметной области. Иными словами, взгляд на проблему и пути ее решения сточки зрения пользователя. «Логический проект» содержит описание архитектуры системы в виде набора объектов, служб и связей между ними. Также рассматриваются модель управления обработкой данных, графический интерфейс пользователя (GUI) и модель (базы) данных. На данном уровне совместно работают эксперты предметной области, системные аналитики и архитекторы. «Физический проект» представляет взгляд на систему с точки зрения программиста и содержит классовую модель системы, спецификации форматов данных и интерфейс программных модулей (API), а также исходный код программных модулей и модульных тестов.

Умение эффективно разрабатывать, производить и эксплуатировать системы, а также вносить в них изменения тесно связано с выбором и использованием модели жизненного цикла системы. На рисунке 2 показана модель жизненного цикла системы, определенная в стандарте Российской Федерации ГОСТ Р ИСО/МЭК 15288 (ISO/IEC 15288) [9]. Данная модель устанавливает общие основы для описания жизненного цикла систем, определяет детально структурированные процессы и соответствующую терминологию. Выбранные из предложенной совокупности процессы могут быть использованы в течение всего жизненного цикла системы для реализации и управления отдельными стадиями жизненного цикла. Иными словами, модель жизненного цикла описывает характер или вид работ, которые доминируют на каждой стадии эволюции системы.

Рис. 2. Модель жизненного цикла системы (ГОСТ Р ИСО/МЭК 15288)

Организация процесса разработки компьютерных моделей ЦОС

Моделирование структуры и поведения сложных систем обычно основывается на междисциплинарном или «метадисциплинарном» подходе, который делает акцент на системное (целостное) содержание и формулировку единой основы деятельности специалистов различных предметных областей. Общая связь науки и инженерии в процессе НИОКР показана на рисунке 3.

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

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

l модель («теория») – акцент на информационно-аналитическую или предметную/ математическая модель, алгоритм, нотацию или язык описания решения класса задач,

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

l открытое ПО (open source) – акцент на реализацию изделия (программу/исходный код),

l изделие (software) – акцент на эксплуатацию/использование изделия – исполняемую программу и пользовательскую документацию,

l открытое решение задачи («ОРЗ»), акцент на интегрированный пакет артефактов, т. е. сборник предметной/математической, конструкторской, эксплуатационной документации и программного обеспечения.

Рис. 3. Связь науки и инженерии в процессе НИОКР (составлено автором)

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

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

Схема жизненного цикла НИОКР (развернутая диаграмма деятельности) приведена на рисунке 5. Процесс НИОКР содержит, по крайней мере, три параллельных процесса:

l процесс администрирования (управления и обеспечения НИОКР);

l процесс разработки (моделирования, конструирования и реализации) системы,

l процесс ОК/А (обеспечения качества/апробации), в частности, оценки качества/адекватности артефактов ИТ-продукта (ИТП) и компонентов системы, т. е. оценки технического качества целевой системы, оценки эксплуатационного качества и оценки адекватности действительных («actual») результатов, которые можно получить с помощью созданной системы, ожидаемым («expected») результатам предметной области или прецедентам (достоверным «декларативным» результатам).

Рис. 4. Блок-схема жизненного цикла НИОКР в области ЦОС (составлено автором)

Программы ЦОС обычно предназначены для «работы» на спецпроцессорах, фирма-производитель которых предоставляет базовую аппаратно-программную платформу и среду разработки. Например, для программирования DSP-процессоров фирмы «Texas Instruments» используется платформа «Code Composer Studio», а для графических процессоров фирмы «Nvidia» – платформа параллельных вычислений «CUDA». Для разработки «высокопроизводительных» компонентов ЦОС на данных платформах используется язык программирования «С».

Для реализации прототипов и испытания математических моделей и алгоритмов преобразований в ИТ-платформе ЦОС выбран язык «Java» [10]. Это, во-первых, связано с тем, что платформа «Java» является хорошо развитой и широко распространенной платформой создания как автономных приложений, так и распределенных приложений «клиент-сервер». Во-вторых, очевидно, что отлаженные, протестированные, хорошо документированные компоненты ЦОС, написанные на языке «Java», гораздо легче конвертировать на любую «фирменную» аппаратно-программную платформу, чем реализовывать с «нуля» математические модели и алгоритмы преобразований ЦОС на языке программирования низкого уровня.

Рис. 5. Схема жизненного цикла НИОКР в области компьютерного моделирования. Диаграмма деятельности (составлено автором)

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

l платформа «Java» предназначена для разработки научно-исследовательских («академических») компонентов и приложений ЦОС на языке «Java». Платформа «Java» включает огромное множество пакетов классов, начиная от элементов графического интерфейса и заканчивая пакетами классов для работы с сетью, базами данных и XML;

u спецификация «JavaServer Faces» предоставляет модель программирования и библиотеку графических веб-компонентов для разработки веб-приложений (интерактивных веб-сайтов) на платформе «Java»;

u спецификация «JavaFX» предоставляет модель программирования и библиотеку графических компонентов для разработки интерактивных приложений с графическим интерфейсом пользователя на платформе «Java»;

l платформа параллельных вычислений «CUDA» предназначена для разработки высокопроизводительных компонентов ЦОС на языке программирования «С» с использованием GPU (графических процессоров) фирмы Nvidia.

Отметим, что первом этапе развития ИТ-платформы ЦОС акцент сделан на поддержку научно-исследовательской и учебно-образовательной (т. е. «академической») деятельности, поэтому «практическая» реализация преобразований ЦОС на спецпроцессорах не является в настоящее время приоритетной задачей. Тем не менее ясно, что реализация преобразований ЦОС на спецпроцессорах или конверсия «академических» программ в промышленную высокопроизводительную среду исполнения (RTE – run-time environment) имеет важное практическое значение и в дальнейшем будет серьезно развиваться. Причем, кроме открытой платформы параллельных вычислений «CUDA», также возможна конверсия созданных программ на другие аппаратно-программные платформы.

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

l модель разработки компьютерных моделей ЦОС (технология «SxP»), т. е. фреймворки/шаблоны документации и реализации ОРЗ ЦОС;

l библиотеку компонентов ЦОС на языке Java;

l коллекцию открытых решений задач (ОРЗ) ЦОС.

Рис. 6. Схема комплексирования базовых программных платформ (составлено автором)

Процесс НИОКР представляет реализацию («практику»), которая не всегда точно соответствует декларации («плану») работы. То же самое можно сказать и о соответствии реальных («actual») и ожидаемых («expected») компонентов комплексного результата НИОКР. Поэтому, кроме основного процесса создания целевой системы, необходимо организовать параллельный процесс оценки качества и адекватности предложенных научно-технических артефактов – гипотез, моделей, методов, алгоритмов, концепций, спецификаций и реализаций программ. В частности, необходимо определить критерии и процедуры оценки качества/адекватности (ОК/А) получаемых результатов НИОКР. Объективные результаты ОК/А научно-технического произведения играют важную роль в принятии решений, как в процессе НИОКР, так и за его пределами.

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

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

Процесс НИОКР» в предметной области ЦОС удобно разделить на следующие фазы:

l «фазу моделирования – ОК/А», т. е. анализа проблемы и изучения объекта/процесса или постановки задачи, формулировки концепции, предметной (математической) модели, метода решения и критерия оценки качества/адекватности (ОК/А) решения, а также испытания предложенного решения, включая редакцию и интеграцию созданных на данной итерации артефактов в пакет проектной документации, включая проведение вычислительных экспериментов по оценке качества/адекватности компьютерной модели, в результате которых выносится решение о дальнейшем продолжении или завершении работы;

l «фазу конструирования – реализации», т. е. проектирования и программирования «компьютерной модели», которая реализует предложенную предметную/ математическую модель (метод) и включает разработку алгоритмов и программ оценки качества/адекватности предложенного решения целевой задачи (алгоритмов и программ ОК/А), а также редакцию/рефакторизацию указанных артефактов.

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

В составе «ИТ-платформы ЦОС» пакет документов «ОРЗ ЦОС» представляет «единицу хранения», т. е. объект информационной базы знаний и технологий. Шаблон пакета документов «ОРЗ ЦОС» включен в технологию «SxP», соответствует рабочему циклу венчурного предприятия [10] и имеет следующую структуру:

Шаблон пакета документов «ОРЗ ЦОС»

l Концепция ОРЗ ЦОС (общее описание предметной/математической модели/метода и критерия ОК/А компьютерной модели ЦОС).

▪ Рецензия концепции ОРЗ ЦОС (экспертная оценка предметной/математической модели/метода и критерия ОК/А).

l Релиз ОРЗ ЦОС

▪ Пакет реализации компьютерной модели ЦОС (пакет информационного, математического и программного обеспечения).

▪ Пакет реализации компьютерной модели ОК/А ЦОС (пакет информационного, математического и программного обеспечения ОК/А).

l Апробация ОРЗ ЦОС (экспертная оценка, сценарии и результаты испытаний компьютерной модели ЦОС).

▪ Аттестация ОРЗ ЦОС (заключение/вердикт экспертов).

Рис. 7. Иллюстрированная схема процесса «НИОКР» в предметной области ЦОС (составлено автором)

Технология «SxP» (сокр. От «Simplex Process / Simple extensible Package») представляет спецификацию «ИТ-платформы ЦОС». Термин «Технология» обычно используется для описания рационального способа достижения цели (типового процесса ЖЦ класса/категории проектов) и инструментария (соответствующих средств) в выбранном виде деятельности. Назначение технологии «SxP» состоит в методологической поддержке и информационном обеспечении разработки компьютерных моделей ЦОС. По своему назначению технология «SxP» (рис. 8) отличается от назначения хорошо известных технологий разработки программных систем, таких, например, как «RUP» [12] (Kratchen, 2002) или «XP» [13] (Bek., 2003), которые в основном ориентированы на разработку программных систем бизнес-назначения. Так, в технологии «RUP» акцент сделан на методику проектирования программных систем с помощью графических шаблонов (UML-диаграмм), а в технологии «XP» акцент сделан на методику проектирования TDD («Тest driven development» – разработка, основанная на тестировании) и использование фреймворка модульных тестов «JUnit» или его репликаций на других языках программирования. В технологии «SxP» дисциплина процесса разработки ОРЗ ЦОС в некоторой степени сочетает как дисциплину разработки «RUP», так и дисциплину разработки «XP» и соответствует рассмотренной выше дисциплине «процесса НИОКР».

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

Рис. 8. Позиционирование технологии «SxP» (составлено автором)

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

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

l используя набор рациональных фреймворков/шаблонов документации быстро создать «макет» документации конкретного проекта «ОРЗ ЦОС»;

l используя набор рациональных фреймворков/шаблонов реализации быстро создать «макет» приложения или компонента, реализующего преобразование ЦОС;

l принимать рациональные решения по развитию проекта «ОРЗ ЦОС» на основе текущего состояния проектной документации НИОКР;

l повышать качество и сокращать сроки исполнения проектов «ОРЗ ЦОС».

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

l шаблон документации ОРЗ ЦОС (пакет HTML-, CSS- и JavaScript-файлов, реализующих фреймворк документации);

l шаблон реализации программных систем ЦОС (пакет Java-файлов фреймворка системы асинхронно взаимодействующих компонент),

l шаблон реализации ОК/А программных систем ЦОС, т. е. шаблон контрольно-измерительных приложений (пакеты программных модулей (Java-файлов), реализующих фреймворк ОК/А преобразований ЦОС).

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

Рис. 9. Структура пакета документации НИОКР (составлено автором)

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

Шаблон пакета документов «ОРЗ ЦОС» основан на феномене гипертекста и построен так, что использование шаблонных HTML-страниц ограничено функцией связывания (суб-) пакетов и терминальных документов – артефактов ОРЗ ЦОС. Шаблон «ОРЗ ЦОС» ориентирует разработчиков на создание модульного, а не монолитного описания решения задачи, что также соответствует модульному принципу разработки программ. Цель унификации представления содержания состоит в следующем:

l обеспечение логической структуры представления результатов НИОКР;

l обеспечение полноты представления результатов НИОКР;

l обеспечение простоты и удобства использования результатов НИОКР («юзабилити»).

Рис. 10. Топ-модель открытого решения задачи (НТП или сущности) (составлено автором)

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

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

Заключение

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

Структура комплексной системы поддержки НИОКР в области компьютерного моделирования систем цифровой обработки сигналов

l Информационная система сопровождения НИОКР:

u система планирования, учета и контроля работ;

u система документирования результатов работ (т. е. интеграция, хранение, обеспечение/ограничение доступа и использования/модификации артефактов НИОКР).

l Интегрированная среда моделирования и ОК/А:

u инструментарий математического моделирования (анализа, визуализации и синтеза цифровых сигналов);

u инструментарий (контрольно-измерительная среда) испытаний («полевые» испытания).

l Интегрированная среда разработки:

u инструментарий проектирования/конструирования изделий;

u инструментарий программирования/реализации изделий;

u инструментарий тестирования изделий («заводские» испытания).

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

Рис. 11. Топ-модель «экономической связи (отношения)» (составлено автором)

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

В заключение уместно вспомнить, что научно-технологический и технико-экономический (организационно-административный) аспекты работы в инновационных проектах имеют одинаково важное значение. Именно поэтому проекты такого типа, например, атомный проект, возглавлялись со-руководителями – Робертом Оппенгеймером и Лесли Гровсом в США или И. В. Курчатовым и Л. П. Берия в СССР. При этом функция ОК/А и ответственности перед «заказчиком» разделена (распределена, т. е. признана совместной) между ними. Данная конфигурация топ-структуры организации деятельности часто используется и на более низких уровнях деятельности [2] (Chichagov, 2016) вплоть до практики парного программирования, которую рекомендуется использовать в процессе разработки средних и крупных программных систем.

Итоги года от Superjob: Следующий год станет последним, когда вырастет количество рабочих мест (https://roem.ru/22-12-2016/238967/1617superjob/)