1 / 40

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

Процесс разработки критических приложений HARMONY. Что такое процесс?. С точки зрения Harmony процесс это:

morna
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related