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

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

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

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

Рис. 1

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

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

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

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

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

• - проект БПО;

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

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

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

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

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

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

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

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

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

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

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

Вестник Сибирского государственного а эрокосмического университета имени академика М. Ф. Решетнева прошивки изделия и спецификацию. Имя выпуска включает тему, изделие и номер изменения сборки.

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

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

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

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

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

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

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

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

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

Рис. 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3

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

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

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

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

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

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

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

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

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