Технология разработки бортового программного обеспечения: управление работами и объектами

УЦК 62.506

А. Н. Антамошкин, О. С. Иноземцева, А. А. Колташев, С. А. Краус

ТЕХНОЛОГИЯ РАЗРАБОТКИ БОРТОВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: УПРАВЛЕНИЕ РАБОТАМИ И ОББЕКТАМИ

Рассмотрена технология разработки бортового программного обеспечения спутников связи и навигации в аспекте обеспечения эффективного управления его конфигурацией в условиях долговременного сопровождения.

В ФГУП «Научно-производственное объединение прикладной механики имени академика М. Ф. Решетне-ва» (НПО ПМ) создана и развивается эффективная технология разработки и долговременного сопровождения бортового программного обеспечения (БПО) спутников связи и навигации [1; 2]. Эта технология базируется на специальном архитектурном расслоении БПО, использовании при его разработке и сопровождении интегрированной среды разработки и верификации БПО и на специальных методах гарантирования качества, базирующихся на трех составляющих: качестве компонентов БПО, качестве управления конфигурацией БПО и качестве верификации и подтверждения БПО [3].

Одной из важных составляющих этой технологии является рассматриваемая ниже модель управления объектами и работами.

Определение объектов разработки и сопровождения БПО основано на концепции архитектурного расслоения БПО (рис. 1). Эта концепция позволяет выделить типовой набор компонентов, слоев и подсистем БПО, функционально привязав их к подсистемам изделия и структурно объединив набором стандартных интерфейсов и слоев, таких как бортовая среда программного функционирования и среда программного управления [2].

Рис. 1

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

Привязка к подсистемам спутника позволяет четко определить требования к программному обеспечению (ПО), ответственность за архитектурное проектирование, системное тестирование и подтверждение БПО, что должно обеспечить прозрачную и эффективную организацию работ и определение типов объектов разработки.

При проектировании и разработке БПО выделяется три уровня (типа) конфигурационных единиц: компонент ПО подсистемы спутника, сборка ПО подсистемы и выпуск БПО [4; 5].

Исходя из структурной декомпозиции БПО (см. рис. 1) при его разработке и сопровождении в модели управления объектами и работами (рис. 2) выделено девять разновидностей объектов:

- проект программы ПО подсистемы;

- проект БПО;

- проект ПО подсистемы;

- проект макропрограмм интегрального управления;

- проект блоков команд управления ПО подсистемы;

- проект входных данных (ВЦ) ПО подсистемы;

- сборка ПО подсистемы изделия;

- сборка БПО изделия;

- выпуск БПО изделия.

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

Компонент ПО подсистемы содержит документацию, исходные модули программы, пакеты для проведения автономной отладки (АО) программы, результаты отладки и результаты работы системы измерения и другие файлы, необходимые для разработки или доработки компонента. Компонент разрабатывается в рамках изделия как объект, унифицированный по соглашениям, интерфейсам, языку программирования и библиотекам типов данных, благодаря чему он может быть пригоден к заимствованию на другие изделия. Унифицикация компонентов позволяет идентифицировать их именем, содержащим версию компонента, без ссылки на изделие. Структура компонента ПО системы определяется средствами его разработки, а именно: кросс-системой программирования на языке Модула-2 [ 1; 2 ].

Сборка ПО подсистемы содержит исходные модули программ ПО подсистемы и все необходимое для проведения сборки. Имя сборки ПО подсистемы включает тему, изделие и номер изменения сборки.

Выпуск БПО изделия содержит сборку БПО изделия (она проводится для отработки и включает сборки ПО подсистем и входные данные ПО бортового комплекса управления (БКУ)), массивы КПИ изделия, материалы

прошивки изделия и спецификацию. Имя выпуска включает тему, изделие и номер изменения сборки.

Примеры построения объектов каждого уровня (типа) представлены ниже (рис. 3).

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

- за идентификацию, состав и согласованность БПО конкретного изделия в целом;

- идентификацию, состав и согласованность ПО подсистемы конкретного изделия;

- состав и согласованность проекта компонента;

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

- состав и целостность выпуска БПО конкретного изделия.

Так, например, сценарий разработки унифицированного компонента БПО предусматривает четыре этапа по уточнению требований к компоненту в процессе его разработки: анализ архитектурного проекта завершен; проектирование завершено; программирование завершено; разработка и автономное тестирование завершены. Эти этапы обеспечивают согласование позиций проектанта ПО подсистемы и разработчика компонента.

Управление работами и объектами обеспечивается тремя подконтрольными электронными архивами: архивом проектов унифицированных программ, архивом изделий БПО и архивом распорядительных документов.

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

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

Информация об объекте разработки и выполнении типового сценария его разработки хранится в виде задания-заключения (ЗАЗ) на разработку компонента или сборку ПО подсистемы. Информация о работах по созданию или изменению ПО подсистемы сохраняется в виде документа запроса-отчета (ЗАО) на доработку ПО подсистемы. Информация об обнаруженных в процессе эксплуатации компонента проблемах хранится в виде отчета о проблеме (ОПР) в программном обеспечении.

Задание-заключение идентифицируется темой, ПО системы, а также ключевым словом «ЗАЗ» и своим порядковым номером. Оно выпускается на все виды работ, которые указываются в его заголовке:

- на разработку программы или входных данных (в виде одного или нескольких программных модулей, являющихся составной частью архитектурного проекта ПО системы);

- изменение программы;

- сборку ПО системы;

- тестирование ПО подсистемы и т. п.

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

Задание-заключение содержит следующую информацию:

- основание для выполнения работы (документ требований, документ архитектурного проекта, ЗАО или ОПР;

- наименования, версии и типы одного или нескольких объектов разработки, содержание их изменения;

- наименование и версию папки проекта программы, которую следует передать в архив программ для хранения после завершения работы;

- наименование, версии и атрибуты объектов, которые следует передать в архив изделий;

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

- подписи исполнителя и согласующих сторон при инициировании работы;

- сроки разработки по этапам детального проектирования и выпуска документа;

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

- информацию о трудоемкости этапов работы и работы в целом;

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

- подпись, утверждающую ЗАЗ.

Запрос-отчет идентифицируется аналогично ЗАЗ:

темой, ПО системы, ключевым словом «ЗАО» и порядковым номером. ЗАО является документом, инициирующим новый цикл работ в рамках ПО подсистемы, и содержит следующие данные:

- перечень создаваемых или изменяемых объектов;

- основание (уточнение исходных данных, ОПР);

- имена изменяемых компонентов объекта;

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

- согласующие подписи о начале работ;

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

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

- утверждающую подпись начальника отдела.

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

Отчет о проблеме ОПР содержит:

- ПО системы и версию, в которой обнаружена проблема;

- компонент ПО системы и его версия, в котором обнаружена проблема;

- фамилию инициатора отчета о проблеме и место обнаружения проблемы;

- фамилию ответственного за ПО подсистемы, выпустившего ОПР;

- название проблемы;

- класс (ошибка программиста, изменение требований и т. п.);

- приоритет (критично, обычный порядок и т. п.);

- описание проблемы;

- среда (инструментальные средства или реальные изделия);

- рекомендуемое решение;

- решение совета по рассмотрению ПО;

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

- ссылки на прилагаемые документы (если есть).

Отчет о проблеме с классом проблемы «Изменение

требований» является основанием для выпуска ЗАО, а ОПР с классом проблемы «Ошибка программиста» -основанием для выпуска ЗАЗ.

Цанные о ЗАЗ, ЗАО, ОПР и разрабатываемых компонентах ПО системы хранятся в базах данных системы управления объектами и работами.

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

Проект программы ПО подсиствлы

Ц окумвнт ацил

Описание программы

Программа и методика испытаний

Л сходные модули программы

Л акеты для проведения АТ программы, зезупьтаты отладки и р аб оты системы измерения______________________________

Цругие файлы, необходимые для разработки или ц ор аб отки пр огр аммы

И ИЯ

Имя программы Версия

Изменение

Структура

Л

DOC (документация);

ADD (т х нош отческие исходные модули

для АО);

SRC (исходные модули проекта);

DBG (пакеты отладки, результаты работы

отладчика);

— IZM (результаты работы системы измерения); СМР (б спомогательная директория для

компиляции),

__файлпроекта-,

вспомогательные файлы (для проведения

разработки/доработки)

Пор яд) к работы

Разрабатыв ается по ЗАЗ

Запись ь базовый архив по утверждению ЗАЗ

Сборка ПО подсистемы шдишя

Документации

Исходные модули программ ПО подсистемы

Файпынеобхсдимые для проведениясборки

Имя

Тема ПО подсистемы Изделие Версия

Структура

Л

D О С (документация);

SRC (исх одные модули);

ABS (исполняемые модули, файлы *.тар); СМР (вспомогательная директория для

компиляции);

ф{шлы проектов

__файлы калтоноеки

__калит дные файлы

Пор яд) к работы

Р азр аб атыв ает сл по ЗАЗ

Запись в базовый архив по утверждению ЗАЗ

Рис. 3

Выпуск ЕЕ

Документация

Спецификация

Техш

Z борка БПО изделия

МассивыКПИ изделия

Материалы прошивки БПО

Ф айпы, не о бх о димые для п

Пия

Т ема Имя выпуска БПО

Структура

А

DOC (документа::

PPZY

МКР1_<Имя по денете]

соотве

лніссішн КПИ

Порядок работы

Запись в архив ЗАЗ

ции архитектурного проекта информация о всех компонентах вместе с графиком их разработки заносится в архив сопровождения объектов, работ и проблем этого изделия.

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

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

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

Модель построена на основе прототипов ее отдельных составляющих, успешно апробированных в более, чем десяти проектах спутников, в том числе в проектах «СЕСАТ», «Экспресс-АМ» и «ГЛОНАСС-М».

В настоящее время данная модель в полном объеме реализуется при выполнении работ по совместному проекту НПО ПМ и Института систем информатики Сибирского отделения Российской академии наук (Новосибирск) - проекту АСПИЦ (автоматизированная система управления проектами, изделиями и документами), направленному на создание высокоэффективной автоматизированной системы управления разработкой и долговременным сопровождением БПО спутников связи и навигации.

В рамках проекта АСПИЦ реализуются электронные архивы сопровождения программных проектов компо-

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

При создании АСПИЦ должен быть реализован и электронный документооборот, обеспечивающий передвижение объектов разработки и электронной распорядительной документации между участниками разработки и архивами, хранение истории объектов, возможность контроля завершенности работ и закрытия проблем.

Реализация проекта АСПИЦ должна существенно облегчить решение проблемы долговременного сопровождения БПО спутников связи и навигации, ставшей особенно актуальной в связи с существенно возросшими сроками активного существования современных спутников.

Библиографический список

1. Колташев, А. А. Эффективная технология управления циклом жизни бортового программного обеспечения спутников связи и навигации / А. А. Колташев // Авиа-космич. приборостроение. 2006. № 12. С. 118-124.

2. Колташев, А. А. Технология разработки и сопровождения мобильного программного обеспечения спутников связи / А. А. Колташев // Изв. вузов. Приборостроение. 2004. № 4. С. 56-63.

3. Колташев, А. А. Технологические аспекты создания бортового программного обеспечения спутников связи / А. А. Колташев, А. Н. Антамошкин // Вестн. Сиб. гос. аэрокосмич. ун-та им. акад. М. Ф. Решетнева / Сиб. гос. аэрокосмич. ун-т. Красноярск, 2005. Вып. 6. С. 93-95.

4. Колташев, А. А. Управление конфигурацией бортового программного обеспечения спутников связи и навигации / А. А. Колташев // Решетневские чтения : материалы X Междунар. науч. конф. / Сиб. гос. аэрокосмич. ун-т. Красноярск, 2006. С. 21-22.

5. Управление конфигурацией бортового программного обеспечения спутников связи и навигации в условиях долговременного сопровождения / А. А. Колташев, О. С. Иноземцева, С. А. Краус и др. // Навигационные спутниковые системы, их роль и значение в жизни современного человека : материалы Всерос. науч.-техн. конф. Железногорск, 2007. С. 86-88.

A. N. Antamoshkin, O. S. Inozemtseva, A. A. Koltashev, S. A. Kraus

ON-BOARD SOFTWARE ENGINEERING: OBJECT AND WORK’S MANAGEMENT

Technology of development and maintenance of the on-board software of communication and navigation satellites is considered in aspect of its efficient configuration management by in conditions of long-term maintenance.