Материал: DO178 Учебное пособие_в183

Рис. 57. Примеры рабочих документов в технологии SCRUM

В перечне свойств/задач продукта (Product Backlog) перечисляются все функциональности, которые могут быть реализованы в данном продукте (столбец “Requirement” – Требование). Для каждого требования указывается его индивидуальный номер (Num), категория (Category), текущее состояние (Status), приоритет (Priority) и оценка трудоемкости его реализации в человеко-часах (Estimate).

В перечне свойств/задач для реализации в данном рабочем цикле (Sprint Backlog) аналогичным образом перечисляются функциональности и задачи, выбранные командой разработчиков для реализации в данном рабочем цикле. В столбце «Описание задачи» (Task Description) стоят их формулировки, в столбцах Originator и Responsible – соответственно, кто является инициатором данной работы и ответственным за ее исполнение, в столбце «Текущее состояние» (Status) – ее текущее состояние (Completed – завершена, Not started – не начата, In progress – в работе).

Следующие 5 столбцов «Hours of work remaining» (Количество оставшихся рабочих человеко-часов) рассчитываются на текущую рабочую недели (5 дней). В каждом столбце с номером дня в текущем рабочем цикле (в данном примере это дни с номерами 6-10) указывается общее число оставшихся человеко-часов работы и их плановое число на выполнение каждой из запланированных работ на данный день. В случае завершенных работ планируется 0 человеко-часов, в остальных случаях – в соответствии с текущим распределением работ, которое может уточняться в зависимости от обстоятельств каждый день на утренних совещаниях. Таким образом, состояние этого перечня обновляется каждый день и вывешивается для всеобщего сведения и стимулирования хода работ в соответствии с принятыми командой разработчиков обязательствами.

Пример экрана завершенности рабочего цикла (Burndown Chart) приведен на Рис. 58. Он показывает расход оставшегося рабочего времени на работы данного цикла.

Рис. 58. Пример экрана завершенности рабочего цикла

Этот экран генерируется автоматически по данным о трудозатратах, сообщаемых всеми участниками разработки. В данном случае видны плоская часть в дни 8 и 9 (отсутствие расхода времени), связанная с выходными и всплеск на день 12, связанный, по-видимому, с работой сверх нормы. Экран завершенности также обновляется ежедневно и служит наглядным стимулом для исполнения запланированных задач в соответствии с плановыми сроками.

Особенностью технологии подвижного программирования является постоянное и тесное общение разработчиков друг с другом и с другими участниками проекта (представителями заказчика). Более результативному общению способствует нетрадиционное размещение разработчиков в одной рабочей комнате (Рис. 59).

Рис. 59. Размещение рабочих мест в общей комнате

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

37. Задания для самопроверки

Составьте матрицу SWOT для известного Вам коллектива разработчиков в расчете на хорошо известный Вам проект.

Сформулируйте какую-либо проблему в этом программном проекте.

Проведите причинно-следственный анализ этой проблемы методом «рыбья кость» с учетом данных SWOT анализа и предложите поправочные действия для преодоления причин возникновения этой проблемы.

Составьте проект сбалансированного экрана результативности на следующий год для известной Вам организации-разработчика программного обеспечения.

Спроецируйте этот экран результативности на личный план известного Вам инженера-разработчика (например, на себя).

8.Сертификация программного обеспечения в авиации

Системы, неправильное поведение которых могут привести к катастрофам, обычно называются критическими (critical mission); к ним, в частности, относится и ПО для авиационных бортовых систем и оборудования. В целях снижения риска неправильного поведения таких систем, для такого рода ПО с начала 1980-х годов введена его обязательная сертификация уполномоченным на то государственным органом, причем процесс сертификации начинается одновременно с началом разработки ПО и продолжается на протяжении всего его жизненного цикла.

В Российской Федерации таким органом является Межгосударственный авиационный комитет с его подразделениями, в США – Федеральная администрация по авиации (FAA), в Канаде – Министерство транспорта, а в ЕС – Европейское агентство по безопасности в авиации (EASA). Все эти органы действуют на основании общих международных стандартов и национальных регулирующих документов.

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

Эти стандарты и рекомендации постоянно совершенствуются, обобщая огромный накопленный опыт создания подобных систем и их применения в реальных условиях, и поэтому являются чрезвычайно ценными для разработчиков и других специалистов, привлекаемых к разработке и дальнейшей эксплуатации данных систем. Основными руководящими документами по сертификации ПО для авиационных бортовых систем и оборудования является серия международных стандартов DO-178/ED-12 “Software Considerations in Airborne Systems and Equipment Certification” и отечественного стандарта КТ-178 «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники».

38. История создания серии документов do-178 и ed-12

В 1980 г. в США в рамках действовавшей тогда Технической комиссии по радио (RTCA – Radio Technical Committee on Aviation) для воздухоплавания создан специальный комитет SC-145 «Цифровое авиационное ПО» и чуть ранее в рамках Европейской организации по электронике для гражданской авиации EUROCAE создана рабочая группа WG-12 для разработки и документирования практик, поддерживающих разработку авиационных бортовых систем и оборудования.

В 1982 г. опубликованы документы DO-178 и ED-12 – результаты работы этих двух групп.

В 1985 г. опубликованы пересмотренный документ DO-178А и идентичный ему пересмотренный документ ED-12А.

В 1989 г. созданы 5 совместных рабочих групп RTCA-EUROCAE для пересмотра документов DO-178А и ED-12А в свете накопленного опыта и практики использования указанных документов.

В 1992 г. опубликованы пересмотренный документ DO-178В и идентичный ему пересмотренный документ ED-12В. Перевод документа DO-178В на русский язык с незначительными дополнениями издан Межгосударственным авиационным комитетом России как стандарт КТ-178В «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники».

В мае 2012 г. опубликованы пересмотренный документ DO-178С и идентичный ему пересмотренный документ ED-12С, однако выход в свет его русского аналога КТ-178С пока не состоялся. Дальнейшее изложение базируется на документе DO-178С.

39. Уровни программного обеспечения

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

В начале разработки выявленных таким образом компонентов программного обеспечения авиационной бортовой системы им присваивается уровень безопасности (safety level), обозначаемый латинскими буквами от A до E, (A – катастрофический, B – аварийный, C – значительный, D – незначительный и E – без влияния на безопасность). Этот уровень характеризует серьезность возможных последствий сбоя или любого вида аномального поведения в работе данного компонента на дальнейшее поведение всего воздушного судна или каких-либо его подсистем.

Компонент программного обеспечения имеет уровень безопасности A, B, C, D или E, если процесс определения безопасности системы показывает, что аномальное поведение данного компонента вызовет отказ какой-либо функции воздушного судна, приводящий к отказному состоянию соответствующего типа в данном воздушном судне, или станет одной из причин такого отказа.

Табл. 23. Уровни безопасности программных компонентов

Если компонент получил уровень E, то дальнейшие требования стандартов DO-178 к нему не применимы.

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

40. Процессы жизненного цикла по авиационных систем

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

Рис. 60. Информационные потоки в ЖЦ бортовой системы и ЖЦ разработки ПО

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

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

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

Разработка. Разработка ведется в соответствии с утвержденным планом создание всех запланированных рабочих документов (продуктов), которая, в свою очередь, подразделяется на 4 частично перекрывающиеся фазы (этапы) разработки:

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

2. Проектирование. Создание высокоуровневого и (или) низкоуровневого проекта исходя из утвержденных требований. Если в процессе разработки исходные требования изменяются, то, соответственно, должны быть изменены и зависящие от них проекты.

3. Кодирование. Создание (написание вручную, заимствование фрагментов уже существующего кода или кодогенерация) кода, реализующего утвержденный проект. Если в процессе разработки проект изменяется, то, соответственно, должен быть изменен и зависящий от него код.

4. Сборка (интеграция). Сборка полученных ранее кодов и их размещение (загрузка) как работающего продукта на заданной аппаратной платформе.

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

Верификация. Различными средствами осуществляется и документируется регулярная проверка корректности, полноты и точности исполнения всех шагов в процессах планирования и разработки.

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

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

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