Работа с требованиями при создании программного...
TRANSCRIPT
All you need is conf.uml2.ru6
Работа с требованиями при создании программного обеспечения бортовой
радиоэлектронной аппаратуры
Лалетин Сергей
ЛАФ 6, 2015 г.
Цель докладаПоказать основные моменты, которые касаются работы с требованиями, при создании программного обеспечения бортовой радиоэлектронной аппаратуры с учетом использования стандарта RTCA DO-178C (Software Considerations in Airborne Systems and Equipment Certification)
3
ЛАФ 6, 2015 г.
План докладаДокумент DO-178CВиды и типы требованийУровни критичности ПОВыявление требованийПроверка требованийДокументыСвязные документы с RTCA DO-178CПрименение UC (UML и SysML)Что бывает, если ....Использованные источникиЗаключение
4
ЛАФ 6, 2015 г.
ВведениеФункциональность современного бортового радиоэлектронного оборудования определяется встраиваемым программным обеспечением.
Общий процент человеческих трудозатрат, связанный с созданием и проверкой бортового ПО, составляет 60 процентов и более, в зависимости от типа оборудования и его критичности.
Любая функциональная особенность должна быть определена требованиями. Требования разрабатывают люди. Людям свойственны ошибки. Фактически, на сегодняшний день, нет общего языка для разработки требований в текстовом виде, как и нет средств автоматизированной или автоматической проверки требований на их корректность и полноту.
Иногда, к разработанным требованиям можно применить высказывание Г. Гегеля: Великий человек обрекает людей на то, что бы они его объясняли.
5
ЛАФ 6, 2015 г.
Стандарт с иллюстрацией
6
CONSENSUS n. Collective opinion or concord; general agreement or accord. [Latin, from consentire, to agree]
Illustration provided by Pat Neilan, UK CAA
ЛАФ 6, 2015 г.
Документ DO-178C
System Life Cycle Processes
Hardware Life Cycle Processes
Software Life Cycle Processes
7
ЛАФ 6, 2015 г.
Процессы (DO-178C)
1. Процессы планирования ПО2. Процессы разработки ПО3. Процессы управления конфигурациями ПО4. Процессы обеспечения качества5. Процессы проверки ПО6. Процессы сертификации ПО
8
ЛАФ 6, 2015 г.
Процессы разработки (DO-178C)
1. Процессы определения требований к ПО2. Процессы определения архитектуры и
дизайна ПО3. Процессы кодирования ПО4. Процессы интеграции ПО
9
ЛАФ 6, 2015 г. 10
Поток информации
Техническая спецификация заказчика - PTS
Документы системного уровня
Документы уровня ПО
Отраслевые стандартыСтандарты заказчика
HLR LLR Derived Req.
ЛАФ 6, 2015 г.
Уровни критичности ПОLevel A – Catastrophic. Отказ может привести к катастрофической отказной ситуацииLevel B – Hazardous. Отказ может привести к непредсказуемой отказной ситуацииLevel C – Major. Отказ может привести к существенной отказной ситуацииLevel D – Minor. Отказ может привести к несущественной отказной ситуации.Level E - No Safety Effect. Отказная ситуация отсутствует
11
ЛАФ 6, 2015 г.
Уровни критичности ПОУровень критичности ПО определяется в результате процесса оценки безопасности системы. Должны быть проанализированы следующие факторы:• Потеря функциональности или
неправильная функциональность• Воздействие внешних факторов
12
ЛАФ 6, 2015 г.
Жизненный цикл разработки (V-Model)
13
ЛАФ 6, 2015 г. 14
Жизненный цикл разработки (V-Model)
Phase 1 Phase 2 Phase 3 Phase … Phase N Phase N+1
ЛАФ 6, 2015 г.
Этапы проекта…………………..SRR - System Requirements ReviewSDR - System Design ReviewPDR - Preliminary Design ReviewCDR - Critical Design ReviewPRR - Production Readiness Review…………………..
15
ЛАФ 6, 2015 г.
Эволюция продукта (разработка)
16
Prototype Blue Label Red label
Black Label Certification Product
ЛАФ 6, 2015 г.
Определение требованияТребование к ПО (Software requirement) – описание того, что должно быть выполнено программным обеспечением, учитывая входные данные и ограничения. Требование к ПО может быть как требованием высокого уровня(LLR), так и требованием низкого уровня(HLR).
17
ЛАФ 6, 2015 г.
Системные требованияСистемные требованя к программному обеспечению, включают в себя:• Функциональные и эксплуатационные
требования• Требования к интерфейсам• Требования к производительности• Требования к безопасности (Safety) и
защищенности (Security)• Требования к обслуживанию
18
ЛАФ 6, 2015 г.
Требования высокого уровняТребования высокого уровня (High-level requirements) – требования к программному обеспечению, разработанные на основе анализа системных требований, требований к безопасности и системной архитектуре
19
ЛАФ 6, 2015 г.
Требования низкого уровняТребования низкого уровня (Low-level requirements) – требования к программному обеспечению, разработанные на основе требований высокого уровня, новых требований, появившихся в процессе разработки (derived requirements) и ограничений. Исходный код разрабатывается на основе требований низкого уровня (LLR).
20
ЛАФ 6, 2015 г.
Derived requirementsНовые требования, появившиеся в процессе разработки (Derived requirements) – требования, появившиеся в процессе разработки программного обеспечения, которые прямо не ссылаются на требования высокого уровня, но уточняют функциональность, определенную системными требованиями или требованиями высокого уровня.
21
ЛАФ 6, 2015 г.
Характеристики требованияТребование должно быть:• тестируемым• реализуемым• ясным для понимания• законченным• полным
22
ЛАФ 6, 2015 г.
Анализ покрытия: Требования vs тестовые процедуры vs кодDead code – Выполняемый код, непокрытый требованиямиExtraneous code – Выполняемый код, непокрытый требованиями, для примера, код унаследованный от другой системыDeactivated code – Выполняемый код, покрытый требованиями, но не используемый, или не предназначенный для использования (robustness programming)
23
ЛАФ 6, 2015 г.
Техники выявления и уточнения требованийАнализ документов и стандартов (отрасль, закачик)Проведение регулярных внутренних и внешних совещанийОфициальная переписка с заказчикоми т.д.
24
ЛАФ 6, 2015 г.
Разработка требований и общий подходДля разработки требования используется глагол “shall”, для рекомендации используется глагол “should”, “must”, “will”.
Примеры требования:The I/O interface shall be ARINC 429.The power-up event shall be logged each time.
25
ЛАФ 6, 2015 г.
Проверка требований высокого уровня1. Проверка на соответствие требованиям
системного уровня2. Проверка на точность и полноту3. Проверка на программно-аппаратную
совместимость 4. Проверка на тестируемость5. Проверка на соответствие стандартам6. Проверка на прослеживаемость (Traceability)7. Проверка на правильность предложенных
алгоритмов
26
ЛАФ 6, 2015 г.
Проверка требований низкого уровня1. Проверка на соответствие требованиям высокого
уровня2. Проверка на точность и полноту3. Проверка на программно-аппаратную
совместимость 4. Проверка на тестируемость5. Проверка на соответствие стандартам6. Проверка на прослеживаемость (Traceability)7. Проверка на правильность предложенных
алгоритмов
27
ЛАФ 6, 2015 г.
ДокументацияThe Plan for Software Aspects of Certification The Software Development Plan The Software Verification Plan The Software Configuration Management Plan The Software Quality Assurance Plan The Software Requirements StandardsThe Software Design StandardsThe Software Code StandardsThe Software Verification results
28
ЛАФ 6, 2015 г.
Связные документы дополнения• RTCA DO-331 "Model-Based Development
and Verification Supplement to DO-178C and DO-278"
• RTCA DO-332 "Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A"
• RTCA DO-333 "Formal Methods Supplement to DO-178C and DO-278A"
• RTCA DO-330 "Software Tool Qualification Considerations"
29
ЛАФ 6, 2015 г.
Что бывает еслиТип ВС: Boeing 777Год происшествия: 2005Авиакомпания: Malaysia AirМаршрут: Perth, Australia - Kuala Lumpur, Malaysia Авиационное происшествие: Воздушное судно совершило самопроизвольный маневрПричина: Отказ в INSДетали: Дефект ПО INS позволил INS принять недостоверные данные от отказавшего акселерометраПоследствия: FAA выпустила экстренную директиву для поддержания летной годности всего парка самолетов типа Boeing 777 и обязала всех эксплуатантов выполнить обновление ПО, с целью устранения дефекта
30
ЛАФ 6, 2015 г.
UML и SysML
• SysML применяется на уровне System Life Cycle Processes
• UML применяется на уровне Software Life Cycle Processes
• Модели не являются требованиями. Требованиями является только текст, содержащий “shall”
31
ЛАФ 6, 2015 г. 32
Requirements Diagram in SysML
ЛАФ 6, 2015 г.
Заключение• Модели из Model Based Requirements
Engineering применяются только как дополнительные разъясняющие материалы к требованиям в текстовом виде
• Модели из Model Based Development (Simulink, SCADE) применяются для разработки систем с высоким уровнем критичности, с последующим самогенерирующемся кодом
33
ЛАФ 6, 2015 г.
Заключение
Для эффективной работы с требованиями, необходимо:• Знание предметной области• Знание и умение применять отраслевые
стандарты• Иметь аналитические способности/навыки• Знание применяемых инструментов• Уметь работать в комманде
34
ЛАФ 6, 2015 г. 35
ЗаключениеRTCA DO в России переводятся и адаптируются в виде КТ МАК.
RTCA DO-178B (1992) -> КТ-178В (2004) RTCA DO-178C (2011) -> КТ-178С (?)RTCA DO-254 (2000) -> КТ-254 (2011)
Отставание в среднем на 10 лет и более
ЛАФ 6, 2015 г.
Использованные источники1. RTCA DO-178C Software Considerations in
Airborne Systems and Equipment Certification www.rtca.org
2. Avionics Magazine www.aviationtoday.com/av/
36
Вопросы?
6-й Летний Аналитический
Фестиваль
г. Иваново20-21 июня 2015
conf.uml2.ru
All you need is …