1. Лекция 8
«Введение в системную инженерию»
МФТИ, Долгопрудный
8 апреля 2012г.

2. Реализация системы
(вынос в реальность)
• Изготовление
• Интеграция
• Верификация
• Валидация
• Передача в эксплуатацию
• Эксплуатация
• Вывод из эксплуатации
2

3. Verivication & validation
The Vee Activity Diagram (Prosnik 2010) Released by the Defense Acquisition
University (DAU)/U.S. Department of Defense (DoD). – из SEBoK v0.71
3
http://www.sebokwiki.org/075/index.php/System_Realization

4. Целеориентированная инженерия
требований и инженерные обоснования
(http://ailev.livejournal.com/811715.html)
• Общие корни: логика
• GORE – “motivation” (ArchiMate, OMG BMM)
• Assurance case (GSN, CAE)
• Design rationale
Нет требований – нет обоснований!
4

5. ISO 15026, assurance case
• Ведется инженерами в обязательном порядке
• Документирует степень, в которой предполагается удовлетворить требования
на текущий момент
• Документирует методы, которыми планируется решить известные на данный
момент проблемы
• Используется менеджерами в моменты принятия решений о дальнейшем
выделении ресурсов (decision gates, anchor points), чтобы увериться в
приемлемости рисков перехода на следующую стадию
• Метафора – «судебное дело» (при пересмотре выделения ресурсов
происходит «доказательство приемлемости риска»).
• Обязательность независимой от разработчиков проверке доказательства
приемлемости рисков
• Составляется по особым правилам (декларации достижимости требований,
аргументы в поддержку деклараций, документальные подтверждения
аргументов)
• Требования к формулировкам (ясность, однозначность...)
• Различный поддерживающий софт
5

6. Assurance case
6

7. Ошибки рассинхронизации менеджерской и инженерной работы
• не включают обоснование реализуемости для проекта целиком на уровне промежуточных уровней
описания. При выполнении практики Интеграция (изготовление, сборка, наладка) получают много
сюрпризов по нестыковкам, объем переделок становится огромным -- время и бюджет увеличиваются в
разы.
• проект планируют так, чтобы у исполнителей не было запасов времени между работами (приоритет
загрузки ресурсов). Это имеет сразу два негативных последствия: случайные отклонения в отдельных
работах невозможно скомпенсировать (все задержки будут просуммированы, и на это время задержится
весь проект), также невозможно будет правильно спланировать промежуточный межстадийный пересмотр
выделения ресурсов -- решение о выделении ресурсов можно будет принимать только по небольшим
работам, но не по всему проекту в целом. То есть пересмотреть проект при таком подходе будет
невозможно: пока пересматриваешь один ручеек этой речки, другие ручейки уже убежали.
• "недопересмотры" и "псевдопересмотры" -- когда решение по выделению ресурсов по факту не может
быть принято, но любое частное решение по какой-нибудь гаечке оформляется как полноценный
пересмотр всего проекта. В тот момент, когда проект заходит в тупик, уже нет способов планово
организовать принятие полноценного корректирующего решения по всем работам проекта -- только
"авральные" внесистемные, внепроцедурные, внерегламентные.
• слишком мало стадий в высокорисковых больших проектах: например, пересмотр выделения ресурсов
случается в самом начале проекта, а затем только при передаче в эксплуатацию (через 5-10 лет после
принятия решения о старте проекта -- проект ведь может быть очень большой!), затем сразу в момент
вывода из эксплуатации (через десятки лет). Нельзя удивляться, что весь проект проходит в непрерывных
авральных совещаниях по переделкам на всех стадиях, но эти совещания мало меняют ход проекта:
принятие решений по отдельной параллельной струйке в речке ведущихся работ мало влияет на течение
других струй. А интегрирующую задвижку на всю речку ведущихся работ просто не предусмотрели, поэтому
о речке в целом мало кто думает (знаменитое "к пуговицам претезний нет?") -- отсюда и огромное число
переделок в таких недосинхронизированных, недопересмотренных проектах.
• при пересмотре выделения ресурсов не меняют требования, хотя и корректируют выделяемые ресурсы.
Требования тоже нужно менять, утверждая под свежевыделенные ресурсы новые требования. Для этого,
конечно, доработка требований должна входить в работы предыдущей стадии.
ISO 15288 не дает практик того, как этих ошибок избежать.
Этот список можно продолжать и продолжать, но все эти ошибки подробно разбираются в рамках конкретных
методов разработки (ICM, RUP, DSDM, OpenUP, spiral model и т.д.). Правда, в каждом методе обсуждается
только класс "любимых" для этого метода ошибок, и игнорируются другие.
7

8. Выбор вида жизненного цикла
• Вид (форма) жизненного цикла, метод (методология) разработки, процесс
разработки (например, software process) – способ связи инженерных практик
(разработка сверху-вниз, снизу-вверх, изнутри-наружу и т.д.) и менеджерских
(пошаговое выделение ресурсов, контроль времени).
• Общая дискуссия: «водопад» против «гибкости» (заранее написанные ноты
против импровизационного джаза).
• Существует множество методов управления ЖЦ/разработки:
– Rational Unified Process (RUP),
– OpenUP,
– Dynamic Systems Development Method (DSDM),
– eXtreme programming
– …
• ISO 15288 никак не проясняет предпочтений к форме ЖЦ, форме разработки
или методу управления ЖЦ, но указывает на необходимость иметь описание
ЖЦ.
• Для описания ЖЦ нужно мыслительно породить и затем документировать его
экземпляр (т.е. продумать проект). Нельзя избежать выбора вида
жизненного цикла/методологии разработки.
• Наш выбор – метод постадийного выделения ресурсов (ICM), дающий
максимальную свободу для выбора инженерных практик и их связи с
потребностями менеджеров в контроле хода работ.
8

9. Метод постадийного выделения ресурсов
• Incremental commitment model (ICM)
• Метод управления жизненным циклом
• опыт множества предыдущих поколений разных
методов УЖЦ (главным образом – используемых
министерством обороны США, т.е. крайне
разнообразных).
• Разработка метода поэтапного выделения ресурсов финансировалась DoD, поэтому все тексты существенно ссылаются
на требования положений документа DoDI 5000.02 к методам управления жизненным циклом. Отсюда в текстах ICM
регулярно путаются «отрасленезависимая» терминология самого ICM и терминология ВПК США типа "milestone A". Но
это неважно, сам ICM независим от требований DoD и может быть использован в любых проектах.
• Автор – Barry Boehm (он же автор «спиральной
модели», первым указавший на необходимость
итераций практик в рамках разработки).
• «Генератор» разных форм ЖЦ – в зависимости от
паттерна рисков проекта
• Дает ответы на вопросы об ошибках координации работ
менеджеров и инженеров (дополняет ISO 15288)
9

10. Необходимость пересмотров выделения ресурсов:
стык мендежерских и инженерных решений
• Теоретический смысл обязательного включения работы по пересмотру
выделения ресурсов между всеми стадиями заключается в необходимости
периодической синхронизации параллельно ведущихся разработок.
• Вероятность того, что трудности возникнут при стыковке готовых ("в металле",
"в бетоне", "в коде" и даже "в голове" для человеко-системной интеграции)
частей системы очень велика, поэтому эта стыковка-интеграция должна
проходить не однократно в момент окончания стадии интеграции
(изготовления, сборки, наладки) и начала стадии эксплуатации, а
существенно чаще, для чего предусматривается несколько пересмотров
выделения ресурсов.
• Решение по продолжению работ должно делаться на основании целостного
описания, а не на основании разрозненных нестыкуемых между собой
разной степени проработанности сведений о системе.
• Пересмотр выделения ресурсов = decision gate
• Пересмотры выделения ресурсов требуют специальных артефактов:
• 1. описание жизненного цикла (определяет моменты пересмотра),
• 2. требований к результатам следующей стадии, и
• 3. инженерного обоснования (assurance case, доказательства приемлемости
рисков перехода к следующей стадии)
10

11. ICM Ancor Point Reviews
Guide for Using the Incremental Commitment Model (ICM) for
Systems Engineering of DoD Projects 11
Version 0.5

12. Генератор видов ЖЦ по профилю рисков
12

13. How to integrate all these
meta(models)/(meta)data?
From FutureModels presentation
13

14. ISO 15926 и жизненный цикл
14

15. ISO 15926 и жизненный цикл
15

16. Организация зачёта
Итоговая работа выполняется в форме подготовки эссе, в свободной форме описывающий системную
инженерию простых объектов (на бытовой и учебной тематике). Ожидаемый объём эссе – не менее трех
страниц текста. Выполнение итоговой работы требует порядка трех-четырех часов времени студента.
В эссе студент должен продемонстрировать владение терминологией системной инженерии, а также
понимание основных практик системной инженерии и умение адаптировать типовой жизненный цикла к
конкретной целевой системе. Студенту предлагается выбрать для эссе одну из следующих систем/сервисов:
• семейный обед
• домашнее животное (кошка, собака, морская свинка – наиболее знакомое)
• поддержка чистоты квартиры
• домашний компьютер
• супружество
• физический эксперимент
• лекция про системную инженерию в физ-матшколе
• реферат
• экзамен учебной сессии
• подготовка текста настоящего эссе
• целевая система, разрабатываемая базовой организацией студента
16

17. Спасибо за внимание
Анатолий Левенчук,
Директор по исследованиям Русского отделения INCOSE
http://ailev.ru
ailev@asmp.msk.su
Виктор Агроскин
vic5784@gmail.com
TechInvestLab.ru
(495) 748-53-88
17