Описание процессов жизненного цикла
ООО «А-РИАЛ»
Системы измерительные «СТАЛКЕР»
Описание процессов, обеспечивающих жизненный цикл специального программного обеспечения «Stalker 1.1 beta»
Москва, 2022 год
Системы измерительные «СТАЛКЕР»
Описание процессов, обеспечивающих жизненный цикл специального программного обеспечения «Stalker 1.1 beta»
Москва, 2022 год
Содержание
1. Общие сведения
2. Ресурс разработки и хранения программного обеспечения
3. Модель разработки программного обеспечения (жизненный цикл)
3.1. Роли персонала разработчика и требования к продукту
3.2. Стадия планирования, анализа требований к ПО и проектирования ПО
3.3. Стадия кодирования (конструирования ПО)
3.4. Стадия тестирования и отладки
3.5. Стадия поддержки ПО
3.6. Стадия эксплуатации и порядок технической поддержки
3.7. Основные средства разработки ПО
3.8. CASE-система сопровождения жизненного цикла ПО
4. Устранение неисправностей, выявленных в ходе эксплуатации ПО
5. Совершенствование ПО
6. Лицензионные ключи программного обеспечения
7. Требования к персоналу
1. Общие сведения
2. Ресурс разработки и хранения программного обеспечения
3. Модель разработки программного обеспечения (жизненный цикл)
3.1. Роли персонала разработчика и требования к продукту
3.2. Стадия планирования, анализа требований к ПО и проектирования ПО
3.3. Стадия кодирования (конструирования ПО)
3.4. Стадия тестирования и отладки
3.5. Стадия поддержки ПО
3.6. Стадия эксплуатации и порядок технической поддержки
3.7. Основные средства разработки ПО
3.8. CASE-система сопровождения жизненного цикла ПО
4. Устранение неисправностей, выявленных в ходе эксплуатации ПО
5. Совершенствование ПО
6. Лицензионные ключи программного обеспечения
7. Требования к персоналу
1. Общие сведения
Специальное программное обеспечение (ПО) систем измерительных «СТАЛКЕР» (далее АПК) разделяется на несколько прикладных частей, в зависимости от назначения, а именно:
- анализ изображений с целю поиска транспортных средств в зоне контроля АПК;
- обработка анализа изображений и формирование информации (пакета данных) о параметрах движения найденного транспортного средства в зоне контроля АПК;
- удаленная настройка и контроль состояния параметров работы АПК.
Часть, отвечающая за анализ изображений — это специальное программное обеспечение АПК, которое обрабатывает видеокадры, поступающие каждые 40 миллисекунд от камеры машинного зрения на вычислительный модуль, установленный внутри АПК, и вычисляет автомобили с установленными государственными регистрационными знаками (ГРЗ), пересекающие зону контроля.
Часть, отвечающая за обработку изображений после анализа и формирование информации — это специальное программное обеспечение АПК, которое собирает характеристики о движении транспортного средства (в т.ч. включая в себя метрологическую часть, с расчетами скорости движения ТС и привязки его положении на проезжей части к точному сигналу времени), формирует пакет данных о характеристиках движения.
Специальное программное обеспечение (ПО) систем измерительных «СТАЛКЕР» (далее АПК) разделяется на несколько прикладных частей, в зависимости от назначения, а именно:
- анализ изображений с целю поиска транспортных средств в зоне контроля АПК;
- обработка анализа изображений и формирование информации (пакета данных) о параметрах движения найденного транспортного средства в зоне контроля АПК;
- удаленная настройка и контроль состояния параметров работы АПК.
Часть, отвечающая за анализ изображений — это специальное программное обеспечение АПК, которое обрабатывает видеокадры, поступающие каждые 40 миллисекунд от камеры машинного зрения на вычислительный модуль, установленный внутри АПК, и вычисляет автомобили с установленными государственными регистрационными знаками (ГРЗ), пересекающие зону контроля.
Часть, отвечающая за обработку изображений после анализа и формирование информации — это специальное программное обеспечение АПК, которое собирает характеристики о движении транспортного средства (в т.ч. включая в себя метрологическую часть, с расчетами скорости движения ТС и привязки его положении на проезжей части к точному сигналу времени), формирует пакет данных о характеристиках движения.
Идентификационные данные метрологической части ПО:
Часть, отвечающая за удаленную настройку, позволяет удаленному пользователю получать текущие значения настроек АПК, изменять их, а также осуществлять мониторинг рабочих параметров систем измерительных, получать текущие видеоизображения от камер АПК, собирать статистику по работе систем измерительных, в т.ч. о зафиксированных проездах ТС в зоне контроля АПК. Весь пользовательский интерфейс программного обеспечения реализован на русском языке.
2. Ресурс разработки и хранения программного обеспечения
Разработка программного обеспечения «Stalker 1.1 beta» на всех этапах производится за счет собственной инфраструктуры, созданной инженернотехническим персоналом ООО «А-Риал». В данную инфраструктуру входят: компьютерное и серверное обеспечение, локально-вычислительная сеть предприятия, включая подключение удаленных пользователей к ней, с применением технологии L2VPN, развёрнутой на собственных серверных мощностях. Для тестирования разрабатываемых частей ПО, собраны специализированные макеты, а также прототипы АПК на основе вычислительных модулей NVIDIA Jetson TX2, NVIDIA Xavier NX. Макеты и прототипы АПК также подключены в сеть предприятия, и разработчики имеют прямой доступ к ним. Все технические средства хранения исходного текста ПО и компиляции исходного текста в объектный код находятся и хранятся на территории Российской Федерации по адресу: г. Москва, ул. Минская, д. 1Г, корп. 2. Исходные тексты ПО хранятся в виде файлов на файловой системе ext4, на SSD диске в персональном компьютере под управлением операционной системы Linux. Объектный код не хранится и после окончательной компиляции ПО (линковки) и объектные файлы удаляются.
Разработка программного обеспечения «Stalker 1.1 beta» на всех этапах производится за счет собственной инфраструктуры, созданной инженернотехническим персоналом ООО «А-Риал». В данную инфраструктуру входят: компьютерное и серверное обеспечение, локально-вычислительная сеть предприятия, включая подключение удаленных пользователей к ней, с применением технологии L2VPN, развёрнутой на собственных серверных мощностях. Для тестирования разрабатываемых частей ПО, собраны специализированные макеты, а также прототипы АПК на основе вычислительных модулей NVIDIA Jetson TX2, NVIDIA Xavier NX. Макеты и прототипы АПК также подключены в сеть предприятия, и разработчики имеют прямой доступ к ним. Все технические средства хранения исходного текста ПО и компиляции исходного текста в объектный код находятся и хранятся на территории Российской Федерации по адресу: г. Москва, ул. Минская, д. 1Г, корп. 2. Исходные тексты ПО хранятся в виде файлов на файловой системе ext4, на SSD диске в персональном компьютере под управлением операционной системы Linux. Объектный код не хранится и после окончательной компиляции ПО (линковки) и объектные файлы удаляются.
3. Модель разработки программного обеспечения (жизненный цикл)
При разработке прикладных частей ПО, указанных в п.1 настоящего описания, в качестве основной стратегии жизненного цикла программного обеспечения, командой разработчиков, в соответствии с ГОСТ Р ИСО/МЭК 12207- 2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», выбрана модель спиральной разработки.
Данная модель была выбрана из-за того, что разрабатываемое ПО подразумевает разработку в виде последовательности версий, но в начале разработки были определены не все требования применительно к прикладным частям и эти требования уточнялись в результате разработки версий каждой разрабатываемой части.
При разработке прикладных частей ПО, указанных в п.1 настоящего описания, в качестве основной стратегии жизненного цикла программного обеспечения, командой разработчиков, в соответствии с ГОСТ Р ИСО/МЭК 12207- 2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», выбрана модель спиральной разработки.
Данная модель была выбрана из-за того, что разрабатываемое ПО подразумевает разработку в виде последовательности версий, но в начале разработки были определены не все требования применительно к прикладным частям и эти требования уточнялись в результате разработки версий каждой разрабатываемой части.
В качестве методологии разработки ПО АПК, была выбрана технология XP (eXtreme Programming – экстремальное программирование), цель которой - справиться с меняющимися требованиями к программному продукту в ходе разработки и повысить качество разработки ПО. Стратегия внедрения при разработке ПО не определяется. Ограничения технологии реализации определяются выбором аппаратной части АПК – платформа NVIDIA Jetson TX2.
3.1. Роли персонала разработчика и требования к продукту
Разработчики ПО АПК, с применением методологии XP, работают как одна команда. В нее входит Заказчик - Технический руководитель разработки, с опытом эксплуатации аналогичных систем более 10 лет. Дополнительный функционал Заказчика выполняет Главный архитектор разработки, изначально выстраивавший основную структуру разрабатываемого ПО.
Заказчик выдвигает требования к ПО и расставляет приоритеты в реализации функциональности для каждой части ПО, указанной в п.1 настоящего описания и модулях в их составе. Заказчику помогают Аналитики команды разработчиков на фазе уточнения задачи. Исполнители команды — это разработчики и тестировщики.
Разработчики ПО АПК, с применением методологии XP, работают как одна команда. В нее входит Заказчик - Технический руководитель разработки, с опытом эксплуатации аналогичных систем более 10 лет. Дополнительный функционал Заказчика выполняет Главный архитектор разработки, изначально выстраивавший основную структуру разрабатываемого ПО.
Заказчик выдвигает требования к ПО и расставляет приоритеты в реализации функциональности для каждой части ПО, указанной в п.1 настоящего описания и модулях в их составе. Заказчику помогают Аналитики команды разработчиков на фазе уточнения задачи. Исполнители команды — это разработчики и тестировщики.
3.2. Стадия планирования, анализа требований к ПО и проектирования ПО
На планировании очередного релиза ПО АПК, Исполнители встречаются с Заказчиком, чтобы выяснить, какую функциональность они хотят получить к следующему релизу, срок выпуска релиза всегда имеет ограниченное время и при разработке ПО и приравнивался к 1 календарному месяцу. На таких встречах 5 Исполнители конкретизируют требования Заказчиков и дробят их на части, реализация которых занимает не более 5-ти рабочих дней.
Задачи записываются в CASE-систему разработки, а Заказчики определяют их приоритет. Когда задачи описаны и оценены, Заказчики просматривают документацию и, при отсутствии замечаний, запускают работы.
Для каждого релиза CASE-система включает область стадии проектирования, которая, в свою очередь, определяет архитектуру релиза (даже если она не отличается от предыдущей версии), описание функций, внешних условий функционирования, интерфейсы, распределение функций между модулями ПО и между пользователями и системой, требования к программным и информационным компонентам. Эта область – «Проектирование релиза» заполняется на основе результатов требований Заказчиков из состава команды. При выполнении данного процесса может быть разработана/модифицирована функциональная спецификация ПО, доработаться архитектура системы, проектируются структуры хранения данных, определяется набор организационных мероприятий, которые необходимы для внедрения ПО, а также перечень документов, регламентирующих использование разрабатываемого ПО АПК.
Результаты стадии: - определяются требования к программным элементам релиза и их интерфейсам;
- требования к ПО анализируются на корректность и тестируемость;
- осознается воздействие требований к ПО на среду функционирования;
- устанавливается совместимость и прослеживаемость между требованиями к ПО и требованиями к релизу;
- определяются приоритеты реализации требований к ПО;
- требования к ПО принимаются и обновляются по мере необходимости;
- оцениваются изменения в требованиях к ПО по графикам работ, стоимости доработки и техническим воздействиям;
- требования к ПО воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон (Заказчики – Исполнители);
- разрабатывается проект архитектуры релиза, если он имеет отклонение от изначально разработанной структуры ПО и устанавливается базовая линия, описывающая составные части релиза, которые будут реализовывать требования к ПО, установленных Заказчиками;
- определяются внутренние и внешние интерфейсы модулей релиза;
- устанавливаются согласованность и прослеживаемость между требованиями к релизу разработки в целом;
- разрабатывается детальный проект каждого программного модуля, описывающий создаваемые релизы;
- устанавливается совместимость и прослеживаемость между детальным проектированием, требованиями и проектированием архитектуры.
На планировании очередного релиза ПО АПК, Исполнители встречаются с Заказчиком, чтобы выяснить, какую функциональность они хотят получить к следующему релизу, срок выпуска релиза всегда имеет ограниченное время и при разработке ПО и приравнивался к 1 календарному месяцу. На таких встречах 5 Исполнители конкретизируют требования Заказчиков и дробят их на части, реализация которых занимает не более 5-ти рабочих дней.
Задачи записываются в CASE-систему разработки, а Заказчики определяют их приоритет. Когда задачи описаны и оценены, Заказчики просматривают документацию и, при отсутствии замечаний, запускают работы.
Для каждого релиза CASE-система включает область стадии проектирования, которая, в свою очередь, определяет архитектуру релиза (даже если она не отличается от предыдущей версии), описание функций, внешних условий функционирования, интерфейсы, распределение функций между модулями ПО и между пользователями и системой, требования к программным и информационным компонентам. Эта область – «Проектирование релиза» заполняется на основе результатов требований Заказчиков из состава команды. При выполнении данного процесса может быть разработана/модифицирована функциональная спецификация ПО, доработаться архитектура системы, проектируются структуры хранения данных, определяется набор организационных мероприятий, которые необходимы для внедрения ПО, а также перечень документов, регламентирующих использование разрабатываемого ПО АПК.
Результаты стадии: - определяются требования к программным элементам релиза и их интерфейсам;
- требования к ПО анализируются на корректность и тестируемость;
- осознается воздействие требований к ПО на среду функционирования;
- устанавливается совместимость и прослеживаемость между требованиями к ПО и требованиями к релизу;
- определяются приоритеты реализации требований к ПО;
- требования к ПО принимаются и обновляются по мере необходимости;
- оцениваются изменения в требованиях к ПО по графикам работ, стоимости доработки и техническим воздействиям;
- требования к ПО воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон (Заказчики – Исполнители);
- разрабатывается проект архитектуры релиза, если он имеет отклонение от изначально разработанной структуры ПО и устанавливается базовая линия, описывающая составные части релиза, которые будут реализовывать требования к ПО, установленных Заказчиками;
- определяются внутренние и внешние интерфейсы модулей релиза;
- устанавливаются согласованность и прослеживаемость между требованиями к релизу разработки в целом;
- разрабатывается детальный проект каждого программного модуля, описывающий создаваемые релизы;
- устанавливается совместимость и прослеживаемость между детальным проектированием, требованиями и проектированием архитектуры.
3.3. Стадия кодирования (конструирования ПО)
На данной стадии строятся прототипы как целой программной части, так и её частей, осуществляется физическая реализация структур данных, разрабатывается программные коды, выполняется отладочное тестирование, создается техническая документация. В результате этапа кодирования появляется рабочая версия релиза. При осуществлении кодирования, выбранная модель - XP позволяет любому разработчику по направлениям править код из данного направления (части), вне зависимости от автора, т.к. доступ к коду есть у всей команды разработки. Кроме этого, данная модель позволяет новые части кода сразу же встраивать в релиз, т.к. Исполнители заливают новую сборку каждые несколько часов и чаще, что влияет на оперативный поиск ошибок в релизе, а также позволяет работать команде с последней версией релиза разрабатываемого ПО – непрерывная интеграция кода.
Из-за обеспечения единого доступа разработчиков к коду, командой были выработаны единые стандарты его оформления, а также активно применяется рефакторинг, направленный на постоянное улучшение дизайна релиза, чтобы привести его в соответствие требования Заказчиков. При разработке ПО «Stalker 1.1 beta», рефакторинг включает удаление дублей кода, повышение связанности и снижение сопряжения. Так как методология XP предполагает постоянные рефакторинги, поэтому дизайн кода всегда остается простым.
Результаты стадии:
- определяются критерии верификации для всех программных модулей, входящих в состав ПО относительно требований п.3.2;
- изготавливаются программные блоки, определенные разработкой ПО;
- устанавливается совместимость и прослеживаемость между программными модулями, требованиями и разработкой ПО в целом;
- завершается верификация программных модулей относительно требований и разработкой ПО в целом;
- разрабатывается стратегия комплексирования для программных модулей, согласованная с разработкой и расположенными по приоритетам требованиями к программным модулям;
- разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие с требованиями к программным средствам, связанными с этими составными частями;
- программные модули верифицируются с использованием определенных критериев;
- изготавливаются программные модули, определенные стадией планирования; 7
- регистрируются результаты комплексного тестирования;
- устанавливаются согласованность и прослеживаемость между всей разработкой и программными модулями;
- разрабатывается и применяется стратегия регрессии для повторной верификации программных модулей при возникновении изменений в них (в т.ч. в соответствующих требованиях, кодах и ПО в целом).
Если Исполнители не успевают выполнить все задачи к дате релиза, то релиз не отодвигается, а урезается часть функционала, наименее важная для Заказчиков.
На данной стадии строятся прототипы как целой программной части, так и её частей, осуществляется физическая реализация структур данных, разрабатывается программные коды, выполняется отладочное тестирование, создается техническая документация. В результате этапа кодирования появляется рабочая версия релиза. При осуществлении кодирования, выбранная модель - XP позволяет любому разработчику по направлениям править код из данного направления (части), вне зависимости от автора, т.к. доступ к коду есть у всей команды разработки. Кроме этого, данная модель позволяет новые части кода сразу же встраивать в релиз, т.к. Исполнители заливают новую сборку каждые несколько часов и чаще, что влияет на оперативный поиск ошибок в релизе, а также позволяет работать команде с последней версией релиза разрабатываемого ПО – непрерывная интеграция кода.
Из-за обеспечения единого доступа разработчиков к коду, командой были выработаны единые стандарты его оформления, а также активно применяется рефакторинг, направленный на постоянное улучшение дизайна релиза, чтобы привести его в соответствие требования Заказчиков. При разработке ПО «Stalker 1.1 beta», рефакторинг включает удаление дублей кода, повышение связанности и снижение сопряжения. Так как методология XP предполагает постоянные рефакторинги, поэтому дизайн кода всегда остается простым.
Результаты стадии:
- определяются критерии верификации для всех программных модулей, входящих в состав ПО относительно требований п.3.2;
- изготавливаются программные блоки, определенные разработкой ПО;
- устанавливается совместимость и прослеживаемость между программными модулями, требованиями и разработкой ПО в целом;
- завершается верификация программных модулей относительно требований и разработкой ПО в целом;
- разрабатывается стратегия комплексирования для программных модулей, согласованная с разработкой и расположенными по приоритетам требованиями к программным модулям;
- разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие с требованиями к программным средствам, связанными с этими составными частями;
- программные модули верифицируются с использованием определенных критериев;
- изготавливаются программные модули, определенные стадией планирования; 7
- регистрируются результаты комплексного тестирования;
- устанавливаются согласованность и прослеживаемость между всей разработкой и программными модулями;
- разрабатывается и применяется стратегия регрессии для повторной верификации программных модулей при возникновении изменений в них (в т.ч. в соответствующих требованиях, кодах и ПО в целом).
Если Исполнители не успевают выполнить все задачи к дате релиза, то релиз не отодвигается, а урезается часть функционала, наименее важная для Заказчиков.
3.4. Стадия тестирования и отладки
Тестирование релиза, при разработке ПО АПК, тесно связано с этапами проектирования и реализации. В релиз Исполнителями встраиваются специальные механизмы, которые дают возможность производить тестирование ПО на соответствие требований к нему, проверку оформления и наличие необходимого пакета документации.
Одной из особенностей применяемой методики - XP является то, что тесты разрабатываемых релизов разрабатываются Исполнителями, при чем в большинстве случаев - до написания фрагмента кода, который нужно будет протестировать в будущем. При таком подходе каждая часть функционала релиза будет покрыта тестами на 100%. Когда разработчики заливают код в репозиторий, модульные тесты запускаются автоматически. При правильном проходе всех тестов, подтверждается правильность направления разработки команды.
Результаты стадии:
- определяются критерии для комплектованных модулей ПО с целью соответствия требованиям Заказчиков;
- комплектованные модули верифицируются с использованием определенных критериев;
- записываются результаты тестирования;
- разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного релиза при проведении изменений в его программных составных частях.
Тестирование релиза, при разработке ПО АПК, тесно связано с этапами проектирования и реализации. В релиз Исполнителями встраиваются специальные механизмы, которые дают возможность производить тестирование ПО на соответствие требований к нему, проверку оформления и наличие необходимого пакета документации.
Одной из особенностей применяемой методики - XP является то, что тесты разрабатываемых релизов разрабатываются Исполнителями, при чем в большинстве случаев - до написания фрагмента кода, который нужно будет протестировать в будущем. При таком подходе каждая часть функционала релиза будет покрыта тестами на 100%. Когда разработчики заливают код в репозиторий, модульные тесты запускаются автоматически. При правильном проходе всех тестов, подтверждается правильность направления разработки команды.
Результаты стадии:
- определяются критерии для комплектованных модулей ПО с целью соответствия требованиям Заказчиков;
- комплектованные модули верифицируются с использованием определенных критериев;
- записываются результаты тестирования;
- разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного релиза при проведении изменений в его программных составных частях.
3.5. Стадия поддержки ПО
Управление документацией ПО. На данном этапе стадии:
- разрабатывается стратегия идентификации документации, которая реализуется в течение жизненного цикла ПО;
- определяются стандарты, которые применяются при разработке программной документации;
- определяется документация, которая производится проектом разработки ПО;
- рассматриваются и утверждаются содержание и цели всей документации ПО;
- документация разрабатывается, делается доступной и сопровождается в соответствии с определенными стандартами и критериями.
Управление конфигурацией ПО. На данном этапе стадии:
- разрабатывается стратегия управления конфигурацией ПО;
- модули, порождаемые процессом или проектом, идентифицируются, определяются и вводятся в базовую линию ПО;
- контролируются модификации и выпуски модулей из состава ПО; обеспечивается доступность модификаций и выпусков для заинтересованных сторон (Заказчики – Исполнители);
- регистрируется и сообщается статус модулей ПО и модификаций;
- гарантируются завершенность и согласованность модулей из состава ПО;
- контролируются хранение, обработка и поставка модулей из состава ПО.
Гарантия качества ПО. На данном этапе стадии:
- разрабатывается стратегия обеспечения гарантии качества;
- создается и поддерживается свидетельство гарантии качества;
- идентифицируются и регистрируются проблемы и (или) несоответствия с требованиями;
- верифицируется соблюдение продукцией, процессами и действиями соответствующих стандартов, процедур и требований.
Верификация ПО. На данном этапе стадии:
- разрабатывается и осуществляется стратегия верификации;
- определяются критерии верификации всех необходимых программных рабочих модулей из состава ПО;
- выполняются требуемые действия по верификации;
- определяются и регистрируются дефекты; - результаты верификации становятся доступными Заказчикам.
Валидация ПО. На данном этапе стадии:
- разрабатывается и реализуется стратегия валидации;
- определяются критерии валидации;
- выполняются требуемые действия по валидации;
- идентифицируются и регистрируются проблемы;
- обеспечиваются свидетельства того, что созданные модули ПО пригодны для применения по назначению;
- результаты действий по валидации делаются доступными Заказчикам.
Ревизия ПО. На данном этапе стадии:
- выполняются технические ревизии и ревизии менеджмента на основе потребностей при разработке ПО;
- оцениваются состояние и результаты действий процесса посредством ревизии деятельности;
- объявляются результаты ревизии всем участвующим сторонам (Заказчики – Исполнители);
- отслеживаются для закрытия позиции, по которым необходимо предпринимать активные действия, выявленные в результате ревизии;
- идентифицируются и регистрируются риски и проблемы.
Аудит ПО. На данном этапе стадии:
- разрабатывается и осуществляется стратегия аудита;
- согласно стратегии аудита определяется соответствие отобранных рабочих модулей ПО;
- проблемы, выявленные в процессе аудита, идентифицируются, доводятся до сведения ответственных за корректирующие действия и затем решаются.
Решение проблем в ПО. На данном этапе стадии:
- разрабатывается стратегия менеджмента проблем;
- проблемы регистрируются, идентифицируются и классифицируются в CASE системе;
- проблемы анализируются и оцениваются для определения приемлемого решения (решений);
- выполняется решение проблем;
- проблемы отслеживаются вплоть до их закрытия;
- известно текущее состояние всех зафиксированных проблем.
Управление документацией ПО. На данном этапе стадии:
- разрабатывается стратегия идентификации документации, которая реализуется в течение жизненного цикла ПО;
- определяются стандарты, которые применяются при разработке программной документации;
- определяется документация, которая производится проектом разработки ПО;
- рассматриваются и утверждаются содержание и цели всей документации ПО;
- документация разрабатывается, делается доступной и сопровождается в соответствии с определенными стандартами и критериями.
Управление конфигурацией ПО. На данном этапе стадии:
- разрабатывается стратегия управления конфигурацией ПО;
- модули, порождаемые процессом или проектом, идентифицируются, определяются и вводятся в базовую линию ПО;
- контролируются модификации и выпуски модулей из состава ПО; обеспечивается доступность модификаций и выпусков для заинтересованных сторон (Заказчики – Исполнители);
- регистрируется и сообщается статус модулей ПО и модификаций;
- гарантируются завершенность и согласованность модулей из состава ПО;
- контролируются хранение, обработка и поставка модулей из состава ПО.
Гарантия качества ПО. На данном этапе стадии:
- разрабатывается стратегия обеспечения гарантии качества;
- создается и поддерживается свидетельство гарантии качества;
- идентифицируются и регистрируются проблемы и (или) несоответствия с требованиями;
- верифицируется соблюдение продукцией, процессами и действиями соответствующих стандартов, процедур и требований.
Верификация ПО. На данном этапе стадии:
- разрабатывается и осуществляется стратегия верификации;
- определяются критерии верификации всех необходимых программных рабочих модулей из состава ПО;
- выполняются требуемые действия по верификации;
- определяются и регистрируются дефекты; - результаты верификации становятся доступными Заказчикам.
Валидация ПО. На данном этапе стадии:
- разрабатывается и реализуется стратегия валидации;
- определяются критерии валидации;
- выполняются требуемые действия по валидации;
- идентифицируются и регистрируются проблемы;
- обеспечиваются свидетельства того, что созданные модули ПО пригодны для применения по назначению;
- результаты действий по валидации делаются доступными Заказчикам.
Ревизия ПО. На данном этапе стадии:
- выполняются технические ревизии и ревизии менеджмента на основе потребностей при разработке ПО;
- оцениваются состояние и результаты действий процесса посредством ревизии деятельности;
- объявляются результаты ревизии всем участвующим сторонам (Заказчики – Исполнители);
- отслеживаются для закрытия позиции, по которым необходимо предпринимать активные действия, выявленные в результате ревизии;
- идентифицируются и регистрируются риски и проблемы.
Аудит ПО. На данном этапе стадии:
- разрабатывается и осуществляется стратегия аудита;
- согласно стратегии аудита определяется соответствие отобранных рабочих модулей ПО;
- проблемы, выявленные в процессе аудита, идентифицируются, доводятся до сведения ответственных за корректирующие действия и затем решаются.
Решение проблем в ПО. На данном этапе стадии:
- разрабатывается стратегия менеджмента проблем;
- проблемы регистрируются, идентифицируются и классифицируются в CASE системе;
- проблемы анализируются и оцениваются для определения приемлемого решения (решений);
- выполняется решение проблем;
- проблемы отслеживаются вплоть до их закрытия;
- известно текущее состояние всех зафиксированных проблем.
3.6. Стадия эксплуатации и порядок технической поддержки
Ввод в эксплуатацию релиза предусматривает его установку на макеты, прототипы и серийные образцы АПК, а также документирование.
Поддержка функционирования релиза осуществляться группой технической поддержки ООО «А-РИАЛ», состоящей из штатных сотрудников, входящих в состав Исполнителей и распределенных по ролям в разработке.
При сопровождении, Исполнители с ролью поддержки продукта – сотрудники ООО «А-РИАЛ», обеспечивают процесс адаптации поставляемого ПО, внесений изменений в ПО (при выпуске новых релизов) и соответствующую документацию, вызванных возникшими проблемами или потребностями в модификации при сохранении неизменными его основных функций – метрологической части, считающейся неизменной и прошедшей аттестацию при испытаниях на предмет регистрации АПК, как средства измерения.
Техническая поддержка конечных пользователей зависит от типа контрактов, по которым реализуются АПК «СТАЛКЕР» и может включать в себя 3 основных уровня:
Первый уровень:
- подразумевает регистрацию обращения и консультацию, оказываемую конечному пользователю АПК в части ПО или партнеру - организации, проводившей работы по внедрению АПК с настройкой соответствующих функций ПО. Осуществляется по телефону и электронной почте в режиме 24х7 (круглосуточно, 7 дней в неделю) – 1 штатный сотрудник и 1 ГПХ.
Второй уровень:
-дистанционное устранение возникших неполадок ПО, осуществляемое техническими специалистами ООО «А-РИАЛ» (1 штатный сотрудник) или организацией, проводившей работы по внедрению АПК в режиме 8х5 (восемь часов в день, пять рабочих дней в неделю) и прошедшей обучение по настройке и администрированию ПО.
Третий уровень:
- оказывается непосредственно ООО «А-РИАЛ» в ситуациях, когда партнер не может справиться с возникшей проблемой самостоятельно и нуждается в помощи технических специалистов производителя – команда из 3-х человек (тестировщик, системный инженер, аналитик).
Вывод из эксплуатации ПО осуществляется в результате его морального, прихода на смену более совершенных продуктов или по иным объективным или субъективным причинам.
Ввод в эксплуатацию релиза предусматривает его установку на макеты, прототипы и серийные образцы АПК, а также документирование.
Поддержка функционирования релиза осуществляться группой технической поддержки ООО «А-РИАЛ», состоящей из штатных сотрудников, входящих в состав Исполнителей и распределенных по ролям в разработке.
При сопровождении, Исполнители с ролью поддержки продукта – сотрудники ООО «А-РИАЛ», обеспечивают процесс адаптации поставляемого ПО, внесений изменений в ПО (при выпуске новых релизов) и соответствующую документацию, вызванных возникшими проблемами или потребностями в модификации при сохранении неизменными его основных функций – метрологической части, считающейся неизменной и прошедшей аттестацию при испытаниях на предмет регистрации АПК, как средства измерения.
Техническая поддержка конечных пользователей зависит от типа контрактов, по которым реализуются АПК «СТАЛКЕР» и может включать в себя 3 основных уровня:
Первый уровень:
- подразумевает регистрацию обращения и консультацию, оказываемую конечному пользователю АПК в части ПО или партнеру - организации, проводившей работы по внедрению АПК с настройкой соответствующих функций ПО. Осуществляется по телефону и электронной почте в режиме 24х7 (круглосуточно, 7 дней в неделю) – 1 штатный сотрудник и 1 ГПХ.
Второй уровень:
-дистанционное устранение возникших неполадок ПО, осуществляемое техническими специалистами ООО «А-РИАЛ» (1 штатный сотрудник) или организацией, проводившей работы по внедрению АПК в режиме 8х5 (восемь часов в день, пять рабочих дней в неделю) и прошедшей обучение по настройке и администрированию ПО.
Третий уровень:
- оказывается непосредственно ООО «А-РИАЛ» в ситуациях, когда партнер не может справиться с возникшей проблемой самостоятельно и нуждается в помощи технических специалистов производителя – команда из 3-х человек (тестировщик, системный инженер, аналитик).
Вывод из эксплуатации ПО осуществляется в результате его морального, прихода на смену более совершенных продуктов или по иным объективным или субъективным причинам.
3.7. Основные средства разработки ПО
ПО «Stalker 1.1 beta» не является кроссплатформенным решением и разработано для работы на операционной системе Ubuntu Linux 18.04. Не рекомендуется использование отличных версий ОС в связи с возможной некорректной работы отдельных компонентов.
Разработка ПО выполнена с помощью следующих основных средств программирования:
- GNU Compiler Collection – набор компиляторов для языков программирования C++;
- Make – автоматизированная среда компиляции;
- Python - высокоуровневый язык программирования общего назначения;
- PHP — скриптовый язык общего назначения;
- NVIDIA TensorRT – среда оптимизирования, проверки и развертывания натренированных нейронных сетей;
- Docker.io - программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации;
- Caffe - среда для глубинного обучения;
- NVIDIA CUDA Deep Neural Network (cuDNN) – библиотека обучения глубоких нейронных сетей.
Компиляция исходного текста в объектный код программного обеспечения осуществляется средствами GCC 5.4.0 и Make 4.1 на персональном компьютере, находящимся по адресу: г. Москва, ул. Минская, д. 1Г, корп. 2.
ПО «Stalker 1.1 beta» не является кроссплатформенным решением и разработано для работы на операционной системе Ubuntu Linux 18.04. Не рекомендуется использование отличных версий ОС в связи с возможной некорректной работы отдельных компонентов.
Разработка ПО выполнена с помощью следующих основных средств программирования:
- GNU Compiler Collection – набор компиляторов для языков программирования C++;
- Make – автоматизированная среда компиляции;
- Python - высокоуровневый язык программирования общего назначения;
- PHP — скриптовый язык общего назначения;
- NVIDIA TensorRT – среда оптимизирования, проверки и развертывания натренированных нейронных сетей;
- Docker.io - программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации;
- Caffe - среда для глубинного обучения;
- NVIDIA CUDA Deep Neural Network (cuDNN) – библиотека обучения глубоких нейронных сетей.
Компиляция исходного текста в объектный код программного обеспечения осуществляется средствами GCC 5.4.0 и Make 4.1 на персональном компьютере, находящимся по адресу: г. Москва, ул. Минская, д. 1Г, корп. 2.
3.8. CASE-система сопровождения жизненного цикла ПО
С учетом особенностей выбора методологии жизненного цикла разрабатываемого ПО, в качестве системы сопровождения разработки применялось CASE-средство «Silverrun», разработанное компанией CSA (Сomputer Systems Advisers, Inc.). Silverrun ориентировано на спиральную модель жизненного цикла программного продукта, предназначено для проектирования и анализа разработки любых информационных систем. Система является модульной и основной модуль, используемый при разработке – это модуль WRM (Workgroup Repository Manager) - менеджер репозитория рабочей группы, позволивший организовать разработку Исполнителем в разрезе выбранного метода разработки - XP.
Используемая CASE-система позволила осуществить следующие основные стратегии, обозначенные на старте разработки ПО:
- поддержка полного жизненного цикла ПО;
- работа с разрозненным репозитарием;
- независимость от какой-либо платформы СУБД;
- поддержка одновременной групповой разработки;
- разработка приложений "клиент-сервер", с ориентацией как на сервер, так и на клиента;
- открытая архитектура;
- организация динамического тестирования и автоматизация процесса технической поддержки;
- создание проектной документации на разрабатываемое ПО.
С учетом особенностей выбора методологии жизненного цикла разрабатываемого ПО, в качестве системы сопровождения разработки применялось CASE-средство «Silverrun», разработанное компанией CSA (Сomputer Systems Advisers, Inc.). Silverrun ориентировано на спиральную модель жизненного цикла программного продукта, предназначено для проектирования и анализа разработки любых информационных систем. Система является модульной и основной модуль, используемый при разработке – это модуль WRM (Workgroup Repository Manager) - менеджер репозитория рабочей группы, позволивший организовать разработку Исполнителем в разрезе выбранного метода разработки - XP.
Используемая CASE-система позволила осуществить следующие основные стратегии, обозначенные на старте разработки ПО:
- поддержка полного жизненного цикла ПО;
- работа с разрозненным репозитарием;
- независимость от какой-либо платформы СУБД;
- поддержка одновременной групповой разработки;
- разработка приложений "клиент-сервер", с ориентацией как на сервер, так и на клиента;
- открытая архитектура;
- организация динамического тестирования и автоматизация процесса технической поддержки;
- создание проектной документации на разрабатываемое ПО.
4. Устранение неисправностей, выявленных в ходе эксплуатации ПО
Перечень этапов процесса устранения неисправностей ПО АПК «СТАЛКЕР» приведен в п.3.5 «Стадии поддержки ПО», этап «Решение проблем в ПО». Общий порядок технической поддержки ПО пользователей приведен в п. 3.6 настоящего описания – «Стадия эксплуатации и порядок технической поддержки».
Штатный порядок работы ПО определяется эксплуатационной документаций на АПК – Руководство по эксплуатации (001.02.77.01-РЭ). Поддерживаемый ПО набор функций определяется требованиями Заказчиками группы разработки.
В случае обнаружения ошибок в работе ПО, которые являются нарушением требований Заказчиков или противоречат порядку работы ПО, описанному в документации, пользователь ПО должен направить заявку в службу технической поддержки (СТП) разработчика или организации, проводившей работы по внедрению АПК. СТП организации, внедрившей АПК, проверяет, при необходимости уточняет полученную заявку и пытается выполнить ее, использую собственные ресурсы и знания (в основном, связанные с настройками ПО).
В случае, если силами СТП организации, внедрившей АПК, выполнить заявку не удается, указанная организация обращается за помощью к производителю ПО – ООО «А-РИАЛ». СТП производителя, проверяет наличие ошибки и рекомендаций по ее устранению в базе знаний технической поддержки.
В случае, если в базе знаний обнаружить описание ошибки не удается, СТП производителя пытается воспроизвести обнаруженную пользователем ошибку в тестовой среде – на макетах и прототипах АПК. После подтверждения найденной ошибки СТП производителя передает разработчикам ПО задание на устранение обнаруженной ошибки.
После устранения неисправности разработчики ПО выпускают обновление к текущей версии ПО (релиз) или включают исправление в следующую версию ПО. Информация о наличии обновления или новой версии ПО доводится до партнеров производителя. В случае наличия у Пользователя контракта или договора на поддержку АПК, Пользователь имеет право на получение обновления ПО АПК дистанционным способом.
Пример исправления ошибки ПО производителем, исправление которой не могло быть реализовано силами партнеров или конечным Пользователем:
Эксплуатация макетов АПК, с устанавливаемыми на них первых «альфа» релизов ПО, показало, что загрузка процессора макетов находится в постоянном значении - 100%, что, в свою очередь, выводило энергопотребление макетов, на значения, значительно превышающие расчетные и неудовлетворительные для разработки в целом (не позволяющие использовать АПК в полностью автономном режиме). На данный показатель макеты выходили при одновременной обработке целей с количеством более 5-ти штук. После постановки задачи внутренними Заказчиками Исполнителям по оптимизации процессорного времени при поиске движущихся ТС в пространстве, а также детальном анализе кода релиза, было выявлено, что при разработке нейросетевых алгоритмов была неверно применены компоненты библиотеки cuDNN, что, в свою очередь не использовало GPU выбранной для АПК платформы и релиз работал стандартным способом, не используя особенности выбранной платформы вычислительного модуля. При следующем релизе были оптимизированы нейросетевые алгоритмы, применяемые для поиска и распознавания ГРЗ с упором на использование GNU платформы, за счет внедрения необходимых функций cuDNN, что позволило добиться снижения затрат использования процессорного времени и нагрузок на него, с отслеживанием 40-50 целей при загрузке процессора - не более 40%.
Перечень этапов процесса устранения неисправностей ПО АПК «СТАЛКЕР» приведен в п.3.5 «Стадии поддержки ПО», этап «Решение проблем в ПО». Общий порядок технической поддержки ПО пользователей приведен в п. 3.6 настоящего описания – «Стадия эксплуатации и порядок технической поддержки».
Штатный порядок работы ПО определяется эксплуатационной документаций на АПК – Руководство по эксплуатации (001.02.77.01-РЭ). Поддерживаемый ПО набор функций определяется требованиями Заказчиками группы разработки.
В случае обнаружения ошибок в работе ПО, которые являются нарушением требований Заказчиков или противоречат порядку работы ПО, описанному в документации, пользователь ПО должен направить заявку в службу технической поддержки (СТП) разработчика или организации, проводившей работы по внедрению АПК. СТП организации, внедрившей АПК, проверяет, при необходимости уточняет полученную заявку и пытается выполнить ее, использую собственные ресурсы и знания (в основном, связанные с настройками ПО).
В случае, если силами СТП организации, внедрившей АПК, выполнить заявку не удается, указанная организация обращается за помощью к производителю ПО – ООО «А-РИАЛ». СТП производителя, проверяет наличие ошибки и рекомендаций по ее устранению в базе знаний технической поддержки.
В случае, если в базе знаний обнаружить описание ошибки не удается, СТП производителя пытается воспроизвести обнаруженную пользователем ошибку в тестовой среде – на макетах и прототипах АПК. После подтверждения найденной ошибки СТП производителя передает разработчикам ПО задание на устранение обнаруженной ошибки.
После устранения неисправности разработчики ПО выпускают обновление к текущей версии ПО (релиз) или включают исправление в следующую версию ПО. Информация о наличии обновления или новой версии ПО доводится до партнеров производителя. В случае наличия у Пользователя контракта или договора на поддержку АПК, Пользователь имеет право на получение обновления ПО АПК дистанционным способом.
Пример исправления ошибки ПО производителем, исправление которой не могло быть реализовано силами партнеров или конечным Пользователем:
Эксплуатация макетов АПК, с устанавливаемыми на них первых «альфа» релизов ПО, показало, что загрузка процессора макетов находится в постоянном значении - 100%, что, в свою очередь, выводило энергопотребление макетов, на значения, значительно превышающие расчетные и неудовлетворительные для разработки в целом (не позволяющие использовать АПК в полностью автономном режиме). На данный показатель макеты выходили при одновременной обработке целей с количеством более 5-ти штук. После постановки задачи внутренними Заказчиками Исполнителям по оптимизации процессорного времени при поиске движущихся ТС в пространстве, а также детальном анализе кода релиза, было выявлено, что при разработке нейросетевых алгоритмов была неверно применены компоненты библиотеки cuDNN, что, в свою очередь не использовало GPU выбранной для АПК платформы и релиз работал стандартным способом, не используя особенности выбранной платформы вычислительного модуля. При следующем релизе были оптимизированы нейросетевые алгоритмы, применяемые для поиска и распознавания ГРЗ с упором на использование GNU платформы, за счет внедрения необходимых функций cuDNN, что позволило добиться снижения затрат использования процессорного времени и нагрузок на него, с отслеживанием 40-50 целей при загрузке процессора - не более 40%.
5. Совершенствование ПО
Работы по совершенствованию ПО АПК включает в себя два основных направления:
- повышение качества и надежности ПО;
- актуализация перечня функций, поддерживаемых ПО.
В ходе постоянно проводимых работ по совершенствованию ПО, используются хорошо зарекомендовавшие себя методы повышения качества и надежности разрабатываемых программных продуктов:
- совершенствование процесса разработки ПО – повышение качества ПО за счет использования современных методик и инструментов разработки;
- совершенствование процесса тестирования ПО – обеспечение необходимой полноты покрытия.
Актуализация перечня функций, поддерживаемых ПО, включает в себя:
- добавление новых и изменение существующих функций в соответствии со стратегией развития ПО;
- добавление новых и изменение существующих функций по предложениям конечных Пользователей АПК и партнеров по их реализации;
- исключение устаревших функций.
Кроме этого, совершенствования ПО АПК так же направлены на максимальное снижение потребления электроэнергии, перенос всех вычислительных процессов в оперативное запоминающее устройство вычислительного модуля АПК, без задействования постоянных запоминающих устройств и внешних носителей, обеспечение более высокой производительности при поиске целей в пространстве и обработки математических вычислений при видеоанализе событий, увеличение точности вычислений. То есть – обеспечение максимальной производительности и функционала прибора при минимальных энергетических затратах.
Все внедряемые в ПО совершенствования основываются на эксплуатации макетов, прототипов и серийных образцов АПК «СТАЛКЕР», за счет анализа получаемой информации в виде лог-файлов от всех разработанных прикладных частей ПО и модулей в их составе.
Например, проведя анализ лог-файлов прикладной части анализа изображений с целю поиска транспортных средств в зоне контроля АПК, было обнаружено, что применяемые стохастические методы требуют многократного угадывания вектора параметров и работают довольно долго по времени. При этом, градиентные методы, которые требуют дифференцирования функции ошибки - «застревают» в локальных минимумах. Командой разработке было принято решение по минимизации функции ошибки. Данная задача была выдвинута в виде требований Заказчиков команды, запланирована и анализирована на предмет минимизации – оптимизации параметров.
Соответственно, в ходе подготовки релиза, было проведено проектирование на предмет изменения в структуре применяемой нейросети, т.к. функция ошибки зависит от выборки, от числа слоев нейросети, нейронов, видов функций активации, и от значения вектора параметров и выбрана позиция альтернативного варианта, который лег в основу нового релиза ПО, обеспечивающего снижение времени поиска цели, при равных использованиях аппаратного вычислительного модуля АПК, по отношению к предыдущему релизу.
Работы по совершенствованию ПО АПК включает в себя два основных направления:
- повышение качества и надежности ПО;
- актуализация перечня функций, поддерживаемых ПО.
В ходе постоянно проводимых работ по совершенствованию ПО, используются хорошо зарекомендовавшие себя методы повышения качества и надежности разрабатываемых программных продуктов:
- совершенствование процесса разработки ПО – повышение качества ПО за счет использования современных методик и инструментов разработки;
- совершенствование процесса тестирования ПО – обеспечение необходимой полноты покрытия.
Актуализация перечня функций, поддерживаемых ПО, включает в себя:
- добавление новых и изменение существующих функций в соответствии со стратегией развития ПО;
- добавление новых и изменение существующих функций по предложениям конечных Пользователей АПК и партнеров по их реализации;
- исключение устаревших функций.
Кроме этого, совершенствования ПО АПК так же направлены на максимальное снижение потребления электроэнергии, перенос всех вычислительных процессов в оперативное запоминающее устройство вычислительного модуля АПК, без задействования постоянных запоминающих устройств и внешних носителей, обеспечение более высокой производительности при поиске целей в пространстве и обработки математических вычислений при видеоанализе событий, увеличение точности вычислений. То есть – обеспечение максимальной производительности и функционала прибора при минимальных энергетических затратах.
Все внедряемые в ПО совершенствования основываются на эксплуатации макетов, прототипов и серийных образцов АПК «СТАЛКЕР», за счет анализа получаемой информации в виде лог-файлов от всех разработанных прикладных частей ПО и модулей в их составе.
Например, проведя анализ лог-файлов прикладной части анализа изображений с целю поиска транспортных средств в зоне контроля АПК, было обнаружено, что применяемые стохастические методы требуют многократного угадывания вектора параметров и работают довольно долго по времени. При этом, градиентные методы, которые требуют дифференцирования функции ошибки - «застревают» в локальных минимумах. Командой разработке было принято решение по минимизации функции ошибки. Данная задача была выдвинута в виде требований Заказчиков команды, запланирована и анализирована на предмет минимизации – оптимизации параметров.
Соответственно, в ходе подготовки релиза, было проведено проектирование на предмет изменения в структуре применяемой нейросети, т.к. функция ошибки зависит от выборки, от числа слоев нейросети, нейронов, видов функций активации, и от значения вектора параметров и выбрана позиция альтернативного варианта, который лег в основу нового релиза ПО, обеспечивающего снижение времени поиска цели, при равных использованиях аппаратного вычислительного модуля АПК, по отношению к предыдущему релизу.
6. Лицензионные ключи программного обеспечения
Лицензионные ключи программного обеспечения - не используются, т.к. при компиляции ПО на каждом устройстве, в базу данных вносится запись MAC адреса этого устройства и ему присваивается уникальный идентификатор. Таким образом исключается возможность несанкционированного копирования ПО. Компиляция работоспособного ПО возможна только на персональных компьютерах ООО «А Риал».
7. Требования к персоналу
К эксплуатации ПО АПК «СТАЛКЕР» и обеспечению поддержки работы программного обеспечения АПК, допускаются лица, ознакомившиеся с эксплуатационной документацией на АПК, прошедшие обучение в ООО «А-РИАЛ» и имеющие практические навыки (не менее 1 года) по администрированию систем семейства Linux.
Лицензионные ключи программного обеспечения - не используются, т.к. при компиляции ПО на каждом устройстве, в базу данных вносится запись MAC адреса этого устройства и ему присваивается уникальный идентификатор. Таким образом исключается возможность несанкционированного копирования ПО. Компиляция работоспособного ПО возможна только на персональных компьютерах ООО «А Риал».
7. Требования к персоналу
К эксплуатации ПО АПК «СТАЛКЕР» и обеспечению поддержки работы программного обеспечения АПК, допускаются лица, ознакомившиеся с эксплуатационной документацией на АПК, прошедшие обучение в ООО «А-РИАЛ» и имеющие практические навыки (не менее 1 года) по администрированию систем семейства Linux.
Рисунок 1. Спиральная стратегия жизненного цикла ПО АПК
