CC BY
61
Левенцов В.А., Костецкий Д.Ю., Аркина К.Г.
РАЗРАБОТКА ИНТЕГРИРОВАННОГО СТАНДАРТА ОБЕСПЕЧЕНИЯ ЦИФРОВЫМИ ДВОЙНИКАМИ НАУКОЕМКОГО ПРОИЗВОДСТВА
Аннотация. Информационные технологии, которые занимают всё большее значение в производственной и иных сферах деятельности организаций, за последнее время превратились из инструмента поддержки производственной деятельности в отдельную полноценную отрасль, которая перманентно масштабируется. В целях снижения издержек на цифровизацию производства предлагается внедрение интегрированного стандарта, который позволяет удешевлять совокупную стоимость владения системами и повышать их управляемость. Представленный в статье интегрированный стандарт предназначен для разработчиков и производителей программного обеспечения. Целью работы является структуризация интегрированных требований перечисленных в статье стандартов в виде локального нормативного акта - стандарта предприятия, предназначенного для обеспечения цифровыми двойниками последующего наукоемкого производства продукции и предоставления сопутствующих услуг.
Ключевые слова. Наукоемкое производство, информационные технологии, цифровизация производства, интегрированный стандарт, цифровые двойники.
Leventsov V.A., Kostetskiy D.Yu., Arkina K.G.
INTEGRATED STANDARD DEVELOPMENT FOR PROVIDING DIGITAL COPY OF SCIENTIFIC PRODUCTION
Abstract. Information technologies, which are becoming increasingly important in the production and other areas of organizations' activities, have recently turned from a tool for supporting production activities into a separate full-fledged industry that is being permanently scaled up. To reduce the costs of production digitalization, we propose to introduce an integrated standard, which makes it possible to reduce the cost of the total cost of ownership of systems and increase their manageability. The integrated standard presented in this article is intended for software developers and manufacturers. The aim of the work is to structure the integrated requirements of the standards listed in the article in the form of a local normative act - an enterprise standard designed to provide a digital copy for the subsequent high-tech production ofproducts and the provision of related services.
Keywords. Science-intensive production, information technology, digitalization of production, integrated standard, digital copy.
Введение
Информационные технологии за последнее время превратились из инструмента поддержки производственной деятельности в отдельную полноценную отрасль, которая перманентно масштабируется. Информационные технологии занимают всё большее значение в производственных и иных сферах деятельности организаций, что отмечается многими авторами [1, 2, 3 и др.]. Они также со временем
ГРНТИ 06.77.02
© Левенцов В.А., Костецкий Д.Ю., Аркина К.Г., 2021
Валерий Александрович Левенцов - кандидат экономических наук, доцент, директор Института передовых производственных технологий Санкт-Петербургского политехнического университета Петра Великого. Дмитрий Юрьевич Костецкий - инженер ООО «СВД Встраиваемые Системы».
Ксения Георгиевна Аркина - кандидат физико-математических наук, доцент, доцент кафедры математического анализа Российского государственного педагогического университета имени А.И. Герцена (г. Санкт-Петербург). Контактные данные для связи с авторами (Левенцов В. А.): 195251, Санкт-Петербург, Политехническая ул., 29 (Russia, St. Petersburg, Politehnicheskaia syr., 29). E-mail: vleventsov@spbstu.ru. Статья поступила в редакцию 30.11.2020.
претерпевают моральное, а порой и физическое устаревание, поэтому их необходимо настраивать, заниматься поддержкой, эксплуатацией, а порой даже внедрять всю систему с нуля. Каждый из этих процессов приводит к издержкам.
Также перед организацией возникают проблемы с поиском нормативной базы, которая удовлетворит заказчика и контролирующие органы, при их наличии в данной сфере. Помимо внешней составляющей, стандарты помогают предусмотреть требования и определить, как должен быть реализован любой процесс. Внедрение собственной нормативной базы, в том числе в области стандартизации и унификации, позволяет организации сократить издержки, улучшить работу на всех стадиях жизненного цикла продукции, а также выйти на больший охват рынка, поскольку соответствие стандарту является гарантией для других сторон договоров сбыта продукции.
Перед руководителями среднего и высшего звена должна быть четко выявлена позиция по данным вопросам: С какой целью необходимы стандарты? Зачем нужна их интеграция? Зачем нужно разрабатывать свой стандарт, оперируя уже внедренными внешними стандартами? В чем преимущество внедрения новых стандартов, если есть уже разработанные свои? В качестве ответа на эти и другие вопросы выступает внедрение интегрированного стандарта в организации. Стандарты удешевляют совокупную стоимость владения системами, поскольку облегчают понимание того, что должно произойти, какие входы и выходы должны присутствовать на каждом этапе жизненного цикла. Тем самым, система становится более управляемой, а сотрудникам требуется меньше времени на то, чтобы разобраться, как правильно выполнять то или иное требование. Особенно это касается новых сотрудников, на обучение которых требуется значительное время.
В среднем, в большинстве организаций испытательный срок, в течение которого оценивается работа кандидата на прием на работу, составляет 3 месяца, а для руководителей - не более 6 месяцев. За это время обычно становится понятно: сможет ли работник проявить себя и включиться в работу. Оценки ИЯ-специалистов по сроку, за который продуктивность выходит на необходимый уровень, разнятся. Стоит учитывать особенности должности, на которую претендует сотрудник, его уровень квалификации, социальной адаптации, условия работы, опыт решений задач в данной сфере. На практике, как правило, период адаптации нового сотрудника приближается к 6 месяцам. То есть, только через полгода руководитель реально сможет понять - насколько эффективна работа данного сотрудника.
Представленный в статье стандарт предназначен для разработчиков и производителей программного обеспечения, а также для организаций, выполняющих оценку соответствия процесса разработки программного обеспечения требованиям настоящего стандарта. Вследствие этого в статье анализируется ряд стандартов на требования, предъявляемые при разработке программного обеспечения в организации. Таким образом, целью работы, в своей основе изложенной в статье, является структуризация интегрированных требований перечисленных стандартов в виде такого локального нормативного акта, как стандарт предприятия.
Обоснование необходимости наличия интегрированного стандарта предприятия В ООО «СВД Встраиваемые Системы» реализован центр технической поддержки выпуска продукции, осуществляющий деятельность, как по телефону, так и по почте. Помимо этого, проводятся курсы по обучению использования программного обеспечения, а также возможен вызов специалиста на территорию заказчика, по договоренности. Специалистами, в том числе контролирующим вопросы качества, были обнаружены недочеты в работе данной службы. Для их устранения была создана экспертная комиссия. На ее заседании были рассмотрены следующие данные (таблица 1):
1. Интенсивность потока заявок, касательно оказания поддержки по каждому продукту (X).
2. Производительность по решению вопросов службой поддержки по каждому продукту (ц).
Таблица 1
Интенсивность потока заявок продукции и производительность по решению вопросов службой поддержки по каждому продукту
Продукт ц
1 0.25 0.35
2 0.29 0.37
3 0.24 0.27
Проанализировав представленный на заседании комиссии материал, было решено рассмотреть следующее:
1. Определить вероятность отказа Ротк:
Ротк = X / (X + Ц).
2. Определить предельные значения относительной пропускной способности (О):
О 1 Ротк.
3. Определить абсолютную пропускную способность (А):
А = X о.
4. Рассчитать среднее время обслуживания (СВО) по каждой заявке:
Тоб = 1 / ц
и среднее время простоя (СВП) службы:
Тпр = 1 / X.
5. Рассчитать вероятность того, что канал обслуживания свободен:
Ро Тпр / (Тпр + Тоб).
6. Сделать выводы по реализации корректирующих мер.
Предельные вероятности отказа, соответственно, для первого, второго и третьего продуктов составили: 0,41, 0,44, 0,47. Значения относительной О и абсолютной А пропускной способности для трех продуктов, соответственно, составят: 0,59 и 0,148; 0,56 и 0,162; 0,53 и 0,12. СВО (в минутах) составляет 2,86; 2,7и 3,7, СПО (минутах) - 4; 3,4; 4,16, соответственно. Вероятность того, что канал свободен, для первого продукта равна 0,58, для второго продукта - 0,56, для третьего продукта - 0,53.
Очевидно, что вероятность занятости канала равна (1 - Ро). Таким образом, для всех продуктов вероятность того, что канал занят, меньше вероятности того, что канал свободен. Относительно изучаемой организации эта вероятность является допустимой, поскольку заказчиками являются государственные организации, выпускающие специальную продукцию. Однако эта вероятность может оказаться недопустимой для иных организаций, поскольку простой может повлечь финансовые потери, а также будет являться угрозой для репутации. В таком случае необходимо привлечь больше сотрудников, а также необходимого оборудования, для оказания технической поддержки.
Для управления персоналом как единой подсистемой организации, которая рассматривается как целостная система, были использованы стандарты: ГОСТ Р МЭК 61508-4-2012, устанавливающий требования, предъявляемые к надлежащему обеспечению безопасности системы и её элементам [4]; ГОСТ Р 56939-2016, регламентирующий требования, предъявляемые для корректного функционирования защищенного программного обеспечения и его среды, обеспечивающей меры по устранению пользователем возникающих ошибок и уязвимостей программного обеспечения [5]; ГОСТ Р 562052014 1БС/Т8 62443-1-1:2009, устанавливающий терминологию и формирующий концептуальные положения и модели применительно к обеспечению безопасности систем промышленной автоматики и контроля [6].
Организации потребуется внедрять и поддерживать процесс разработки, подходящий для обеспечения последующего наукоемкого производства продукции и предоставления сопутствующих услуг. Наукоемкое производство понимается в соответствии с [7]. Особое место наукоемкого производства в Российской Федерации отмечается в исследованиях [8, 9].
Для понимания того, каким образом будут осуществляться этапы процесса, а также каким образом будет осуществляться его менеджмент, должны быть учтены следующие факторы: характер, продолжительность и сложность деятельности; требуемые этапы процесса, включая применимый анализ в ходе реализации процесса; требуемая верификация и валидация; ответственность и полномочия; потребности во внутренних и внешних ресурсах; необходимость управления взаимодействием между лицами, участвующими в процессе; уровень управления процессом, ожидаемый потребителями и другими соответствующими заинтересованными сторонами; документированная информация, необходимая для демонстрации того, что исходные требования выполнены.
Организации потребуется предусмотреть следующие факторы (согласно ГОСТ Р ИСО 9001-2015 [10]): функциональные и эксплуатационные требования; информация, полученная раннее при выполнении подобных работ по разработке; нормативные правовые акты и иные нормативные требования; стандарты или своды правил; потенциальные последствия отказов, связанные с характером продукции и услуг.
Требования к входным данным, изложенным выше, относится их полнота, прозрачность и точность. Между этими данными не должно быть противоречий. Все эти данные должны быть задокументированы в принятой в организации форме согласно ее локальным нормативным актам. Организация должна предусмотреть комплекс решений, которые следует предпринять для управления процессом разработки согласно [10]: результаты, которые должны были быть достигнуты, определены; проведены действия по верификации для обеспечения соответствия результатов разработки входным требованиям; проведены анализы для оценки способности результатов разработки соответствовать требованиям; предприняты любые необходимые действия по проблемам, выявленным в ходе анализа или деятельности по верификации и валидации; сохранена документированная информация об этих действиях.
Требования по изменению процессов организации, служащих для корректного соответствия регулирующих документов и во избежание негативных последствий, должны включать идентификацию, обзор и контроль. Также организация должна предусмотреть то, каким образом она собирается подтверждать выполнение требований, с точки зрения документированной информации. Отсутствие обязательной формы по оформлению документации может привести к отрицательным последствиям. В общем виде информация должна содержать отчеты об изменениях при разработке, о результатах анализа, о санкционировании изменений, о действиях, принятых для предупреждения негативных последствий.
Трассировка является одной из важнейших частей разработки программного обеспечения, поскольку позволяет получать дополнительные возможности в жизненном цикле [11]. Исходя из определения, 1хасегои1е - пошаговое выполнение программы с остановками на каждой команде или строке, трассировка позволяет получать полную информацию о процессе на всех стадиях жизненного цикла разработки. Таким образом, можно анализировать и понимать: на какой стадии работы находятся остальные члены команды. Примером таких действий является работа, где аналитик требований поставил определенные задачи и требования на различные части разработки, и в дальнейшем появилась необходимость в аналитике того, было ли какое-либо частное требование учтено на определенной итерации работы. Также это позволяет определять - на какой именно итерации были положительные и отрицательные результаты тестирования.
Также трассировка между фактами жизненного цикла разработки является решением для реализации управления всем процессом, поскольку позволяет участникам команд получать полную информацию о статусе проекта. Это позволит проанализировать влияние дефектов на определенные требования, а также узнать о готовности каких-либо элементов к тестированию. При работе с внешним регулированием трассировка помогает наблюдать за действиями каждого члена команды, что позволяет увеличить объемы работы, контролировать исполнительность и анализировать результаты и их влияние на весь цикл. Таким образом, это позволяет внешней стороне контролировать любые изменения в сборке, а также результаты тестов.
Рекомендуемые действия: для возможности создания и поддержки трассировочных связей, которые позволяют связывать между собой несколько артефактов, необходимо использовать оптимальное решение в виде универсального пользовательского интерфейса. При этом ни одному участнику не нужно будет переключаться на другие инструменты, что позволит эффективно использовать время работы. Изначально необходимо определить актуальные стратегии по созданию связей, а также те значимые вопросы, на которые необходимо иметь возможность отвечать. Очень важно для дальнейшего продолжения реализовать одну стратегию и достигнуть в ней успеха. Для эффективного результата рекомендовано использовать систему оценки степени завершенности проекта путем предоставления запросов и отчетов.
Также необходимо поэтапно оценивать готовность работ, что послужит превентивной мерой для действий с обнажающимися дефектами. Одной из возможностей данного решения является создание трассировочных связей, используя которые не приходится выделять большие ресурсы на ее поддержание, что является удобной мерой для создания отчетов. Используя вариант, который характеризуется построением связей путем работы с открытыми сервисами, можно внедрить необходимые указания действий, происходящих на всех этапах жизненного цикла. Трассировочные связи можно использовать для работы путем открытых интерфейсов, в содействии с сервисами «Открытые сервисы для совместной работы жизненного цикла» для построения связей [12].
И последним важным действием является выбор масштабируемого решения, которое будет решать все задачи в дальнейшем, путем поддержки открытых и гибких интеграций. Учитывая развитие информационных технологий и появление с каждым днем новых продуктов на рынке, решение для управления жизненным циклом тоже должно меняться и развиваться.
Взаимодействие в организации - это нечто большее, нежели просто поддержание комфортных рабочих отношений. Грамотное взаимодействие между сотрудниками может привести к улучшению качества продукта, что приведет к большей удовлетворенности конечного потребителя и впоследствии к привлечению новых заказов и прочим преимуществам. Управляя любым процессом, рекомендуется предусмотреть возможности по улучшению взаимодействия команды, что будет способствовать большей предсказуемости и контролю производимых решений. Однако стоит учитывать, что для любых промышленных предприятий должен быть предусмотрен отдельный канал, доступ к которому не должен осуществляться сквозным способом, поскольку уровень безопасности отличен от критического уровня иных трактов.
Данные инструменты должны быть направлены на то, чтобы команда смогла определиться с теми направлениями, которые на данный момент являются ключевыми. Любая организация должна стремиться к автоматизации ручных задач, где не требуется творческое мышление. Например, информационные панели и отчеты предоставляют информацию, которая снабжает персонал актуальными необходимыми данными. Грамотно проработанный пользовательский интерфейс предоставляет информацию работнику напрямую, при этом, переходя на работу с иным программным обеспечением, не требуя смены контекста.
Рекомендуемые действия: внедрить инструмент, с помощью которого вся информация будет доступна мгновенно; создать такую среду, через которую можно будет полностью вести обсуждение по ходу выполнения этапов, которые отразятся на итоговом плане; обеспечить доступ сотрудников к связанным данным, учитывая политику конфиденциальности и уровень секретности; обеспечить возможность онлайн обсуждения, утверждения, а также оперативного реагирования на новые требования и желания заинтересованных сторон.
Рекомендуемые действия для непрерывного улучшения процесса разработки: объяснить целесообразность непрерывного улучшения процесса, персонал необходимо убедить в том, что это поможет работать более эффективно, снизить инциденты и прочие несоответствия; улучшать процесс путем корректировки планов с учетом решения тех проблем, которые происходят в текущей ситуации; использовать прорывные улучшения, используя спецификации процессов, шаблонов, которые могут использовать сразу несколько команд в одном инструменте; поощрять сотрудников за участие в улучшении процесса, даже самые неоднозначные, на первый взгляд, решения могут привести к значительным модификациям; при определении последующих целей по улучшению процесса нужно вести документированную оценку предыдущих улучшений, которые будут свидетельствовать о прогрессе, а также являться почвой для последующих улучшений.
Чтобы понимать, что организация движется в сторону улучшения, необходимо предусмотреть метрики успешности, по которым можно будет судить: меняется ли что-то в сторону развития. Необходимо определить области, которые нуждаются в улучшении, идентифицировать цели в этих областях и обеспечить отслеживание прогресса на пути достижения этих целей. Согласно Дж. Кейперсу [13], в тех проектах, где предусматривается метрика успешности, наблюдаются значительные преимущества на выходе.
Рекомендуемые действия: определить метрики производительности; руководствоваться при анализе по необходимым решениям фактами, основываясь на отчетах, а также данными с панели управления, в которой содержится информация касательно итога деятельности сотрудников; необходимо реализовывать те решения, которые являются результатами фактических действий сотрудников, полученных путем внедрения тех метрик, которые приняты в организации; определив систему оценки, нужно начинать деятельность по анализу постепенно, понемногу наращивая интенсификацию; необходимо найти уязвимость, выбрать как с ней поступать, руководствуясь данными, получаемые от собираемой с персонала документированной информации.
Выявленные трудности практической реализации риск-ориентированного мышления: • руководство управляет рисками обособленно от установленных процедур и процессов, часто интуитивно, поэтому реальные результаты, как правило, не регламентируются и не прослеживаются;
• результаты оценки риска (по установленным процедурам) не интересны руководству, так как не дают понимания, что и сколько потеряет организация. Документированная информация, согласно стандартам, может быть реализована в любом удобном для организации виде;
• в реестры рисков попадают давно известные и уже обработанные риски, что вызывает сопротивление и воспринимается как вынужденная мера, т.е. обязательная формальность для поддержания сертификата. В регулирующих документах не предусмотрены требования того, каким образом должна осуществляться процедура менеджмента рисков. Исходя из этого, организация сама решает, в какой форме будет подтверждаться соответствие выполнения;
• вероятность перемножается на последствия без опоры на достоверную информацию;
• участники процессов не всегда понимают собственную процедуру по работе с рисками, т.е. внедрение проходит без разъяснений и обучения.
Рекомендации по решению вышеприведенных проблем: учитывать уже предпринятые меры в отношении рисков; в оценку результатов работы руководителя могут быть включены результаты работы с рисками в его зоне ответственности; в каждом процессе должны быть разработаны свои критерии и инструменты для работы с рисками; руководству нужна оценка рисков в момент принятия решений.
Рекомендуется проводить матричный анализ рисков и возможностей. Он не требуется стандартами, но помогает понять: с какими проблемами может столкнуться организация, а также оценить вероятность этого возникновения и масштаб угрозы при реализации этого риска. Ниже приведен пример анализа риска при разработке: R=S X О, где 8 - опасность события, О - вероятность возникновения опасного события. В организации представлена следующая градация оценки риска: 75-100 значительные последствия для финансов и репутации; 30-75 умеренные последствия для финансов и репутации; 10-30 небольшие последствия для финансов и репутации.
Разработанный на основании [14] план, по которому должна происходить оценка риска, выглядит следующим образом: обозначается опасное событие; определяется ответственная сторона, которая управляет данным риском; определяется уровень опасности, к которой приведет данный инцидент; определяется вероятность его возникновения; производится оценка риска; предусматриваются мероприятия по обработке риска; исходя из градации оценки определяется стратегия действия с риском: устранение, снижение последствий его возникновения, страхование, принятие данной ситуации; определяется планируемое и фактическое время по нейтрализации риска (в случае принятия решения по устранению риска).
Пример выполнения анализа риска по процессу разработки программного обеспечения:
• сложность проекта оказалась выше прогнозируемой;
• главный конструктор опытно-конструкторских работ не учел всех рисков;
• последствия опасного события 8 (6) - средний уровень угрозы;
• вероятность опасного события О (5) - средний уровень угрозы;
• оценка риска Я = 30 - небольшие последствия для финансов и репутации;
• мероприятия по обработке риска: анализ требований технического задания, устных требований заказчика, технической сложности, наличие экспертизы и доступности квалифицированного персонала;
• принято решение принять риск - не предпринимать никаких действий по потенциальному возникновению опасной ситуации;
• планируемое и фактическое время по нейтрализации риска - необходимость в процедуре отсутствует.
Апробация разработанного интегрированного стандарта производилось в организации впервые. Ниже (в следующем разделе статьи) представлена разработанная версия интегрированного стандарта предприятия разработки программного обеспечения.
Интегрированный стандарт предприятия разработки программного обеспечения I. Определения, обозначения и сокращения.
Данный документ составлен, конгруэнтен сокращениям и формулировкам ГОСТ Р МЭК 61508-42012, ГОСТ Р 56939-2016, ГОСТ Р 56205-2014 1ЕС/Т8 62443-1-1:2009. Сокращения: СТО - Стандарт организации; НТД - Научно-техническая документация; ОКР - Опытно-конструкторская работа; ПО -Программное обеспечение; СМК - Система менеджмента качества; ЗБ - Задание по безопасности.
II. Общие положения.
Состав этапов жизненного цикла разработки программного обеспечения ООО «СВД Встраиваемые Системы» обеспечивает соответствие процесса разработки программного обеспечения интегрированным требованиям ГОСТ Р МЭК 61508-3 и ГОСТ Р 56939. Перечень этапов представлен в таблице 2.
Выходные данные каждого этапа подлежат верификации с учетом требований подраздела 7.9 ГОСТ Р МЭК 61508-3. Выходные данные каждого этапа должны быть задокументированы с учётом требований раздела 5 ГОСТ Р МЭК 61508-1. Документы, которые являются выходными данными этапов, являются элементами конфигурационного управления. Порядок конфигурационного управления специфицируется в плане конфигурационного управления каждого проекта. Данный стандарт должен интерпретироваться с учётом особенностей ОКР. Например, если в составе разрабатываемого программного обеспечения не требуются файлы конфигурации, то деятельность по разработке структуры файлов конфигурации выполнять не требуется.
Таблица 2
Матрица требований к жизненному циклу программного обеспечения
Этап Наименование этапа Требования нормативных актов
МЭК 61508-3 ГОСТ Р 56939
0 Управление проектом - 5.7, 5.8, 5.9
1 Спецификации требований 7.2 5.1
2 Планирование верификации и валидации 7.3 -
3 Эскизное проектирование 7.4.1-7.4.4 5.2
4 Техническое проектирование 7.4.5 5.3
5 Разработка программных модулей 7.4.6
6 Модульное тестирование 7.4.7
7 Интеграция программного обеспечения 7.4.8
8 Программно-аппаратная интеграция 7.5
9 Разработка эксплуатационной документации 7.6 5.5.3.2
10 Валидация проекта 7.7 5.4
11 Завершение проекта разработки ПО 7.8 5.6
III. Требования к этапам разработки.
Этап 0 «Управление проектом».
Цель этапа: организация работ по проекту; управление документацией, конфигурацией, инфраструктурой разработки и людскими ресурсами.
Комментарии: данный этап не является частью жизненного цикла разработки программного обеспечения, но необходим как деятельность по планированию мер по обеспечению качества проекта, в том числе мер менеджмента функциональной безопасности; сведения об управлении проектами приведены, например, в пункте В.1.1 стандарта МЭК 61508-7.
Входные данные: приказ генерального директора об опытно-конструкторских работах.
Деятельность (выполняемые работы): разработка документов, являющихся выходными данными.
Выходные данные: устав проекта; схема организационной структуры проекта; таблица участников проекта; план проекта; план обеспечения безопасности; план управления конфигурацией; заявка на обучение персонала (при необходимости); реестр поставщиков проекта.
Этап 1 «Спецификация требований».
Цель этапа: документирование функциональных требований и требований к безопасности (функциональной и информационной) к программному обеспечению, создаваемому в рамках проекта.
Комментарии: этап спецификации требований позволяет зафиксировать в согласованном и утвержденном документе, являющимся элементом конфигурационного управления, все требования заказчика к программному обеспечению, создаваемому в рамках проекта, кроме того, спецификация требований является важным входным документом для сертификации (оценки соответствия) программного
обеспечения по требованиям функциональной и/или информационной безопасности; если разработка программного обеспечения выполняется в рамках проекта (ОКР) по созданию программно-аппаратного комплекса и требования к программному обеспечению определены в спецификации требований программно-аппаратного комплекса, то разработка отдельной спецификации требований для программного обеспечения не является обязательной.
Входные данные: приказ генерального директора об опытно-конструкторских работах; устав проекта.
Деятельность: анализ функций программного обеспечения; анализ требований по безопасности; анализ спецификаций требований к системе, в состав которой будет входить разрабатываемое программное обеспечение; анализ отказов; анализ ограничений, связанных со взаимодействием между аппаратным и программным обеспечением; разработка выходных документов.
Выходные данные: спецификация требований (техническое задание, исходные данные); спецификации требований по безопасности для оценки соответствия (при необходимости).
Комментарий: в качестве примера отдельной спецификации требований по безопасности можно привести документ «Задание по безопасности».
Этап 2 «Планирование верификации и валидации».
Цели этапа: четкая организация работ по верификации и валидации проекта; возможность демонстрации соответствия результатов проекта требованиям нормативных документов.
Входные данные: спецификация требований.
Деятельность: анализ спецификации требований; анализ инструментальных средств; анализ методов и мер разработки; разработка выходных документов.
Выходные данные: план верификации и валидации; реестр инструментов верификации.
Этап 3 «Эскизное проектирование».
Цель этапа: создание архитектуры (проекта верхнего уровня) программного обеспечения, соответствующей спецификации требований; выбор инструментальных средств разработки программного обеспечения.
Входные данные: спецификация требований.
Деятельность (выполняемые работы): анализ спецификации требований; анализ плана верификации и валидации; разработка документов, являющихся выходными данными.
Выходные данные: пояснительная записка эскизного проекта (проект верхнего уровня) программного обеспечения.
Этап 4 «Техническое проектирование».
Цель этапа: разделение элементов проекта верхнего уровня на программные модули; проектирование программных модулей; разработка структур файлов конфигурации; разработка схем организации данных (баз данных); прототипирование графических интерфейсов пользователя; определение состава модульных тестов.
Входные данные: спецификация требований; пояснительная записка эскизного проекта.
Деятельность: анализ спецификации требований; анализ пояснительной записки эскизного проекта; разработка технического проекта (детального проекта, проекта нижнего уровня).
Выходные данные: пояснительная записка технического проекта (проекта нижнего уровня).
Этап 5 «Разработка программных модулей».
Цель этапа: создание (кодирование) программных модулей.
Комментарий: на данном этапе выполняется написание программных модулей на соответствующих языках программирования, автокодах, технологических языках, модельно-ориентированных языках и т.д. Также создаются файлы конфигурации и формируются необходимые базы данных.
Входные данные: пояснительная записка технического проекта (проект нижнего уровня).
Деятельность (выполняемые работы): кодирование, генерация объектного кода; создание файлов конфигурации и баз данных; тестирование программных модулей разработчиком (ad-hoc testing); автоматизированный статический анализ программных модулей; ревизия кода; разработка модульных тестов (выполняется независимо от разработки модулей).
Выходные данные: зафиксированные в системе конфигурационного управления исходные и объектные коды программных модулей, файлы конфигурации и базы данных, модульные тесты.
Этап 6 «Модульное тестирование».
Цель этапа: верификация программных модулей.
Комментарий: данный этап выполняется специалистами, независимыми от команды разработчиков.
Входные данные: программные модули, модульные тесты, технический проект.
Деятельность (выполняемые работы): модульное тестирование; создание протоколов модульного тестирования.
Выходные данные: протоколы модульного тестирования.
Этап 7 «Интеграция программного обеспечения».
Цель этапа: формирование из разработанного программного обеспечения программного продукта и проверка корректности его функционирования.
Входные данные: пояснительные записки эскизного и технического проектов, программные модули, модульные тесты.
Деятельность (выполняемые работы): интеграция программного обеспечения; выполнение фаззинг-тестов, пентестов, нагрузочных тестов, тестов производительности и других тестов интеграции программного обеспечения; разработка отчетов (актов, протоколов, журналов) о тестировании интеграции.
Выходные данные: альфа-версия программного продукта; отчеты о тестировании интеграции программного обеспечения.
Этап 8 «Программно-аппаратная интеграция».
Цель этапа: интеграция программного продукта с целевыми аппаратными средствами, тестирование программно-аппаратной интеграции.
Комментарий: в результате выполнения данного этапа происходит отработка функционирования программного продукта на конкретных аппаратных конфигурациях, предназначенных для реального применения.
Входные данные: альфа-версия программного продукта, пояснительная записка эскизного проекта.
Деятельность (выполняемые работы): программно-аппаратная интеграция; тестирование программно-аппаратной конфигурации с помощью методик и тестов, применявшихся при тестировании интеграции программного обеспечения, а также с помощью дополнительных тестов (методов), указанных в эскизном проекте.
Выходные данные: бета-версия программного продукта; отчеты о тестировании программно-аппаратной интеграции.
Этап 9 «Разработка эксплуатационной документации».
Цель этапа: разработка эксплуатационной документации.
Входные данные: спецификация требований, проект верхнего уровня, бета-версия программного продукта.
Деятельность (выполняемые работы): создание документации.
Выходные данные: комплект эксплуатационной документации.
Этап 10 «Валидация проекта».
Цель этапа: проверка выполнения приказа генерального директора о выполнении ОКР.
Комментарий: на этом этапе руководство организации оценивает пригодность разработанного продукта к применению по целевому назначению, возможность организации тиражирования и поставок.
Входные данные: приказ генерального директора об опытно-конструкторских работах, бета-версия продукта, тестовая документация, эксплуатационная документация.
Деятельность (выполняемые работы): выполнение тестов; анализ результатов.
Выходные данные: релиз-версия программного продукта; акт валидации (предварительных испытаний, квалификационного тестирования); приказ генерального директора о присвоении документации изделия литеры «О».
Этап 11 «Завершение проекта разработки программного обеспечения».
Цель этапа: обеспечение регистрации и сохранности результатов выполнения проекта, организации серийного производства и технического сопровождения.
Комментарии: этап завершения проекта необходим как запланированная деятельность, обеспечивающая корректное завершение проекта.
Входные данные: акт валидации проекта (предварительных испытаний, квалификационных испытаний и т.п.).
Деятельность (выполняемые работы): изготовление подлинников продукта и сдача их в архив; создание оригинал-макетов эксплуатационной программной документации; разработка технических условий и инструкции по тиражированию; изготовление контрольной копии дистрибутива для тиражирования; регистрация журнала производства (тиражирование).
Выходные данные: акт сдачи программной, конструкторской и технологической документации в архив научно-технической документации; технические условия и инструкция по тиражированию (производству) изделия; контрольная копия дистрибутива для тиражирования; журнал производства (тиражирования). Заключение
Сегодня организациям при реализации основной деятельности практически во всех отраслях промышленности требуется внедрение все большего количества стандартов. В связи с увеличением их объема встает вопрос: каким образом должно осуществлять планирование и контроль их исполнения. Интеграция в организации разработанного стандарта внесла улучшение в качество управления процессом разработки программного обеспечения для внутреннего пользования. Он предназначен как для руководителей организации, так и для иных ответственных лиц, связанных с деятельностью по разработке и оценке программного обеспечения.
В данной статье рассмотрена реализация интегрированного стандарта организации с учетом требований международных стандартов. В дальнейших исследованиях будет проведен анализ иных процессов с целью создания комплексного стандарта, который будет содержать описание всех этапов со всем массивом данных, что позволит не только оптимизировать затраты организаций, но и оптимизировать наукоемкое производство с целью увеличения глубины передела промышленной продукции [15].
ЛИТЕРАТУРА
1. Карлик А.Е., Платонов В.В., Тихонова М.В., Павлова О. С. Межфирменная кооперация как фактор промышленного развития в информационно-сетевой экономике // Известия Санкт-Петербургского государственного экономического университета. 2020. №6 (126). С. 7-14.
2. Александрова А.В., Алетддинова А.А., Афтахова У.В. и др.Формирование цифровой экономики и промышленности: новые вызовы. СПб.: Изд-во Политехнического ун-та, 2018. 659 с.
3. Bodrunov S., Plotnikov V. Strategie Aspects of National Socio-Economic Development // Proceedings of the 34th International Business Information Management Association Conference (IBIMA) - Vision 2025: Education Excellence and Management of Innovations through Sustainable Economic Competitive Advantage, 13-14 November 2019, Madrid, Spain. P. 4916-4922.
4. ГОСТ Р МЭК 61508-4-2012. Функциональная безопасность систем электрических, электронных, программируемых электронных связанных с безопасностью. Жизненный цикл программного обеспечения. М.: Стандартинформ, 2014.
5. ГОСТ Р 56939-2016. Защита информации. Разработка безопасного программного обеспечения. Требования к разработчику. М.: Стандартинформ, 2018.
6. ГОСТ Р 56205-2014. Сети коммуникационные промышленные. Защищенность (кибербезопасность) сети и системы. М.: Стандартинформ, 2016.
7. Соловейчик К.А., Микитась А.В., Аркин П.А. Методологические подходы к определению терминологии в области наукоёмкого производства // Известия Санкт-Петербургского государственного экономического университета. 2020. № 5 (125). С. 9-18.
8. Соловейчик К.А., Салкуцан С.В., Аркин П.А. Процессы управления наукоемкими производствами в машиностроении. СПб: ПОЛИТЕХ-ПРЕСС, 2018. 438 с.
9. Соловейчик К.А., Плотников В.А., Аркин П.А. Развитие системы кафедр университетов, созданных на базе промышленных предприятий, как инструмент интеграции производства, науки и образования // Известия Санкт-Петербургского государственного экономического университета. 2018. № 5 (113). С. 85-91.
10. ГОСТ Р ИСО 9001-2015. Системы менеджмента качества. Определение требований к продукции и услугам. М.: Стандартинформ, 2020.
11. Управление жизненным циклом: приложения. [Электронный ресурс]. Режим доступа: http://www.its-hop.ru/Pyat-printsipov-upravleniya-zhiznennym-tsiklom-prilozheniya (дата обращения 12.11.2019).
12. Платформа прикладных программ IBM TRIRIGA версия 3 выпуск 5.3 OSLC Integration Guide. [Электронный ресурс]. Режим доступа: https://www.ibm.eom/support/knowledgecenter/ru/SSHEB3_3.5.0/ com.ibm.tap.doc/pdfs/ pdf_tap_oslc.pdf (дата обращения 19.11.2019).
13. Достижение совершенства в программной инженерии. [Электронный ресурс]. Режим доступа: https://ru.scribd.com/document/276865413/Capers-Jones (дата обращения 13.11.2019).
14. Управление рисками для устойчивого роста в эпоху инноваций. [Электронный ресурс]. Режим доступа: https://www.pwe.ru/ru/riskassuranee/publieations/assets/pwe-2018-risk-in-review-russian.pdf (дата обращения 19.11.2019).
15. Соловейчик К.А., Аркин П.А. Методические вопросы стимулирования роста глубины передела промышленной продукции субъектами Российской Федерации // Известия Санкт-Петербургского государственного экономического университета. 2015. № 4 (94). С. 25-30.
