Процесс разработки критических приложений HARMONY Процесс HARMONY

Что такое процесс? С точки зрения Harmony процесс это: – Спецификация серии последовательных деятельностей, выполняемых группой взаимодействующих специалистов, в результате которой создается когерентное множество артефактов, одним из которых является требуемая система Harmony – результат развития и совершенствования процесса ROPES (Rapid Object-Oriented Process for Embedded Systems). Используется преимущественно а аэрокосмической и оборонной промышленности США Процесс HARMONY 2

Как выполняется разработка критичного ПО Хорошо известен V-цикл проектирования и разработки критичного ПО: ТЗ ПСИ ЭП ПИ ТП Процесс HARMONY 3

Макроцикл HARMONY System Engineering (HARMONY-SE) Приемочное тестирование ТЗ ПСИ ЭП ПИ Software Engineering (HARMONY-SWE) ТП Процесс HARMONY 4

Обзор HARMONY-SE Анализ требований Фиксация требований UC системы Идентификация вариантов использования системы Варианты использования системы Сценарии UC «ЧЯ» Модель системы как «Черный ящик» Операционные контракты Функциональный анализ системы Модель системной архитектуры с операц. контрактами Операционные контракты (наборы функциональных требований) Архитектурный дизайн Сценарии UC «БЯ» Проектирование архитектуры системы Сценарии UC «ЧЯ» Проектирование архитектуры подсистем Модели физич. подсистем с операц. контрактами АО/ПО Репозит. тестовых данных Репозитарий модели и требований Требования Разработка АО/ПО Процесс HARMONY 5

Обзор HARMONY-SE Анализ требований – Фиксирование требований и группировка их в варианты использования. Функциональный анализ системы – Идентификация и верификация/валидация операций системы (т. е. множества функциональных требований) на основе вариантов использования. Проектирование архитектуры системы – Опциональная декомпозиция операций системы и привязка их к (функциональным или физическим) подсистемам. Определение интерфейсов подсистем. Проектирование архитектур подсистем – Разделение операций между компонентами системы (программными и/или аппаратными). Определение интерфейсов компонентов подсистемы. Процесс HARMONY 6

HARMONY-SE: Анализ требований Репозитарий модели и требований Требования UC системы Фиксация требований Идентификация вариантов использования системы Требования фиксируются для их последующей трассировки Возможно хранение требований в Word/Exel/Requisite. PRO/DOORS (для трассировки требований используется Rhapsody Gateway) Варианты использования идентифицируют на основе Процесс HARMONY 7

HARMONY-SE: Анализ требований Фиксация требований ADMS – Aircraft Defense Management System Процесс HARMONY 8

HARMONY-SE: Анализ требований Фиксация требований Процесс HARMONY 9

HARMONY-SE: Анализ требований Идентификация вариантов использования Каждый вариант использования показывает один из аспектов функционирования системы, рассматриваемой как «черный ящик» Процесс HARMONY 10

HARMONY-SE: Анализ требований Детализация вариантов использования С любым визуальным объектом с помощью механизма anchor может быть сопоставлено требование. Процесс HARMONY 11

Обзор HARMONY-SE Анализ требований – Фиксирование требований и группировка их в варианты использования. Функциональный анализ системы – Идентификация и верификация/валидация операций системы (т. е. множества функциональных требований) на основе вариантов использования. Проектирование архитектуры системы – Опциональная декомпозиция операций системы и привязка их к (функциональным или физическим) подсистемам. Определение интерфейсов подсистем. Проектирование архитектур подсистем – Разделение операций между компонентами системы (программными и/или аппаратными). Определение интерфейсов компонентов подсистемы. Процесс HARMONY 12

HARMONY-SE: Функциональный анализ Анализ требований Фиксация требований UC системы Идентификация вариантов использования системы Модель системы как «Черный ящик» Операционные контракты Варианты использования системы Сценарии UC «ЧЯ» Функциональный анализ системы При функциональном анализе выполняются: - Анализ «черного ящика» ( «ЧЯ» , BB) для каждого варианта использования (UC) - Анализ целостности вариантов использования Процесс HARMONY Репозит. тестовых данных Репозитарий модели и требований Требования 13

HARMONY-SE: Функциональный анализ Для артефактов функционального анализа целесообразно создавать пакет с подпакетами анализа каждого варианта использования Процесс HARMONY 14

HARMONY-SE: Функциональный анализ – это преобразование функциональных требований в операционные контракты ОК (Op. Con) задаются в виде сообщений (запросов сервиса). На диаграмме последовательности Op. Con могут включать: – Пред- и пост- условия (могут задаваться состояниями) – Кросс-ссылки на другие диаграммы последовательности – Ограничения Процесс HARMONY 15

HARMONY-SE: Функциональный анализ Op. Con изменения состояния/режима Op. Con деятельности Процесс HARMONY 16

HARMONY-SE: Функциональный анализ Структура системы, необходимая для выполнения каждого UC, описывается с помощью диаграммы определения блоков Почему в Sys. ML используют блоки? - Не нужно определять классы; - Позволяют анимировать модель. - Блоки взаимодействуют через порты – именованные точки соединения Процесс HARMONY 17

HARMONY-SE: Функциональный анализ Сценарий каждого варианта использования обычно описывают набором диаграмм последовательностей Диаграммы последовательности: - Сценарии «Солнечного дня» - Сценарии «Черного дня» Процесс HARMONY 18

HARMONY-SE: Функциональный анализ Анализ целостности вариантов использования 1) Блоки, представляющие систему в каждом варианте использования, помещают на одну диаграмму 2) На эту диаграмму перетаскивают блоки, моделирующие актеров, и связывают соответствующие порты Процесс HARMONY 19

HARMONY-SE: Функциональный анализ Поведение каждого блока удобно описывать в виде конечного автомата Это позволяет верифицировать модель с помощью симуляции (анимации) Процесс HARMONY 20

HARMONY-SE: Функциональный анализ Валидация и верификация модели на основе симуляции (анимации) Сохранение модели Запуск симуляции Процесс HARMONY 21

HARMONY-SE: Функциональный анализ Валидация и верификация модели на основе симуляции (анимации) Предыдущее состояние Последний сработавший переход Текущее состояние Процесс HARMONY 22

HARMONY-SE: Функциональный анализ Основные артефакты Sys. ML, создаваемые в ходе модельно-управляемого системного инжиниринга Взаимосвязь артефактов функционального анализа Процесс HARMONY 23

Обзор HARMONY-SE Анализ требований – Фиксирование требований и группировка их в варианты использования. Функциональный анализ системы – Идентификация и верификация/валидация операций системы (т. е. множества функциональных требований) на основе вариантов использования. Проектирование архитектуры системы – Опциональная декомпозиция операций системы и привязка их к (функциональным или физическим) подсистемам. Определение интерфейсов подсистем. Проектирование архитектур подсистем – Разделение операций между компонентами системы (программными и/или аппаратными). Определение интерфейсов компонентов подсистемы. Процесс HARMONY 24

HARMONY-SE Анализ требований Фиксация требований UC системы Идентификация вариантов использования системы Варианты использования системы Сценарии UC «ЧЯ» Модель системы как «Черный ящик» Операционные контракты Функциональный анализ системы Модель системной архитектуры с операц. контрактами Операционные контракты (наборы функциональных требований) Архитектурный дизайн Сценарии UC «БЯ» Проектирование архитектуры системы Сценарии UC «ЧЯ» Проектирование архитектуры подсистем Модели физич. подсистем с операц. контрактами АО/ПО Репозит. тестовых данных Репозитарий модели и требований Требования Разработка АО/ПО Процесс HARMONY 25

Организация SE-модели Область требований Область системной архитектуры Область спецификации физической архитектуры (Подсистем) Процесс HARMONY 26

Harmony Цикл инкрементной разработки ( «Микро-цикл» ) Требования, сценарии и др. артефакты Системный инжиниринг (HARMONY-SE) Модель Тестовые сценарии Модель требований и логической структуры Реализация Приемочное тестирование Система, прошедшая внутреннюю валидацию и верификацию Тестирование Ревизия Дизайн Анализ Программный инжиниринг (HARMONY-SWE) Процесс HARMONY 27

Микроцикл HARMONY Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; Реализация -- создание корректно работающего компонента или подсистемы; Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; Ревизия (Party!) -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY 28

Микроцикл HARMONY: Анализ: • • определение прототипа – выбор требований, подлежащих реализации на витке объектный анализ – идентификация необходимых объектов и классов Стратегии выявления объектов: – – – – Идентификация существительных Предоставляемые сервисы Транзакции Физические устройства Ключевые концепции Устойчивые данные Элементы управления Процесс HARMONY 29

Микроцикл HARMONY Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; Реализация -- создание корректно работающего компонента или подсистемы; Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; Ревизия (Party!) -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY 30

Микроцикл HARMONY: Дизайн В ходе стадии «Дизайн» к прототипу применяют шаблоны проектирования Шаблоны проектирования надежности: - Однородная избыточность Неоднородная избыточность Санитарная проверка Монитор-актуатор Наблюдатель Администратор (функциональной) безопасности Дизайн или Проектирование – применение к прототипу шаблонов проектирования, необходимых для привидения его в соответствие заданным критериям Процесс HARMONY 31

Микроцикл HARMONY: Дизайн: Архитектура подсистем и компонентов – из каких исполняемых модулей состоит система или подсистема; Архитектура развертывания – элементы, относящиеся к различным инженерным областям: программной, аппаратной, механической, химической, тестовой и т. д. ; Архитектура распределения – размещение объектов в изолированных адресных пространствах, способ нахождения друга, порядок их совместной работы; Архитектура надежности – как выявляются, изолируются и устраняются сбои в процессе функционирования системы; Архитектура ресурсов и параллельности –потоки, их диспетчеризацию и их синхронизацию при использовании разделяемых ресурсов; Архитектура безопасности –элементы системы, необходимые для обеспечения информационной безопасности. Процесс HARMONY 32

Микроцикл HARMONY Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; Реализация -- создание корректно работающего компонента или подсистемы; Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; Ревизия (Party!) -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY 33

Микроцикл HARMONY: Реализация: • • Трансляция модели в коды Тестирование программных модулей (функциональное, • Ревизия соответствия программных модулей модели качества сервиса, покрытия кода, стресс-тестирование, нагрузочное ) Результатом фазы реализации являются высококачественные компоненты и подсистемы создаваемой системы. Процесс HARMONY 34

Микроцикл HARMONY Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; Реализация -- создание корректно работающего компонента или подсистемы; Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; Ревизия (Party!) -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY 35

Микроцикл HARMONY: Тестирование – валидация качества уже высококачественного продукта 1) Базовые тест-векторы (диаграммы последовательностей) уже созданы на этапе формализации требований к системе. 2) Фаза «Тестирование» актуальна при внесении заказчиком изменений в требования в ходе проекта Выявление дефекта требует повтора микроцикла для его устранения и повторного тестирования Процесс HARMONY 36

Микроцикл HARMONY Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; Реализация -- создание корректно работающего компонента или подсистемы; Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; Ревизия (Party!) -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY 37

Микроцикл HARMONY: Ревизия: - Ревизия выполнения графика проекта. При необходимости - может выполняться реорганизация проекта, передача части работ в аутсорсинг, перегруппировка ресурсов проекта; Ревизия архитектуры. Архитектура оценивается на различных фазах проекта, тем не менее ревизия необходима – просчеты в архитектуре системы дорого стоят. Ревизия процесса. Проводится оценка самого процесса разработки и его рабочих процедур – при необходимости процесс корректируется. Ревизия рисков. Проверяется, как контролируются риски, предусмотренные в плане управления рисками, а так же какие новые риски появились. Процесс HARMONY 38

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

Спасибо за внимание! 196135, г. Санкт. Петербург, пр. Юрия Гагарина 23 тел. : (812) 702 -0833 факс: (812) 373 -0497 web: http: //www. swd. ru/ Процесс HARMONY 40