Тьюториал TechInvestLab "Введение в системную инженерию" (второй день из трёх), 15 января 2013г.

1. Тьюториал
«Введение в системную инженерию»
Москва
15 января 2012г. (второй день из трёх)

2. Жизненный цикл системы
• Всегда полный (в отличие от ЖЦ проекта)
• Стадии – отрезки времени, границы по
смене главной инженерной деятельности
(cognitive framework)
• Система – отнюдь не всегда «времени
эксплуатации»!!!
t
замысел прекращение
существования
2

3. Разнообразие типовых жизненных циклов
(природы системы, стадий жизненных циклов, инструментов)
Софт Концепция Разработка Поддержка Списание
Эксплуатация и
Оборудование Идея Проектирование Изготовление Списание
поддержка
Определение
Использование
Персонал требуемых Приобретение Обучение Отставка
компетенций и рост
Проектирование
Эксплуатация
Здание Визуализация сооружения и Согласование Строительство Разборка
площадки и поддержка
Природный
Приобретение Разработка Эксплуатация Рекультивация
ресурс
Определение Графическое Пилотное Использование и
Процесс выхода представление
Описание
внедрение совершенствование Ликвидация
Система Идея Разработка Изготовление Использование Поддержка Списание
3

4. Жизненный цикл объектов работы
(комплектующих/предметов снабжения)
IEC/EN 81346, RDS-PP, KKS
Ситуация
Объект
Спецификация
функции
Спецификация
компонента
Спецификация
модели
Индивидуальная
карточка экземпляра
Физический
экземпляр
Реальный, функционирую
Объект «мотор» щий
Запланированный,
«Мотор» в обычном языке
историческая запись, и т.п.
Система жива, пока жива её функция!
Конструкция может меняться (атомы менее важны, чем идея).

5. Рынок как механизм согласования целей и
разделения труда
Не все задачи решаются инженерно
Жизненный цикл и поставки
5
http://www.econlib.org/library/Essays/rdPncl1.html

6. ЖЦ задвижки в ISO 15926 (краткая форма)
6

7. ЖЦ задвижки в ISO 15926 (чуть более полная форма)
7

9. Жизненный цикл холона
(диаграмма Harold “Bud” Lawson)
9

10. Разнообразие интеграции данных жизненного цикла
в эко-системе инжиниринга
уровни структуры вещества * уровни воплощения
Замысел Архитектура «Рабочка» Изготовление Эксплуатация
Макро PLM1 PLM2 PLM3 PLM4 PLM5
Мезо PLM6 PLM7 PLM8 PLM9 PLM10
Микро PLM11 PLM12 PLM13 PLM14 PLM15
Нано PLM16 PLM17 PLM18 PLM19 PLM20
Специализация/профессионализация: в каждой клетке
Интеграция в продукте: вся таблица (эко-система!)
КРУПНЫХ ПРОЕКТОВ С ОДНОЙ PLM НА ВСЕХ – НЕ БЫВАЕТ!
ДВЕ РАЗНЫХ УСТАНОВКИ PLM одного вендора – РАЗНЫЕ УСТАНОВКИ!
PLM нуждается в интеграционном решении!
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. Минимум: инженерия и операции
(рис.17 из ISO TR 19760)
[менеджерская]
В тексте путаются enterprise view и management view 12

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

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

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

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

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

18. Обеспечивающие СИСТЕМЫ
18

19. Дерево дел и состояний (+ обоснования)
Узлы – кейсы (группы работ по достижению состояния альф)
(upper level = “mission”)
5
1 2
• Sacrifice 1 (consequences)
• Justification 1 (Why)
• Sacrifice 2 Vision N
• Justification 2
(World State)
• Sacrifice N
• Justification N
•Justification 1
4
•Justification 2
3
Work N •Justification N
(Activity)
6
World State World State World State World State
N+1.1 N+1.2 N+1.3 N+1.N
19

20. Полнота представления
информации жизненного цикла
ISO 15926
... (+ обоснования)
Карточки Основ (+ состояния альф)
V-диаграмма, горбатая диаграмма (+практики)
Колбаска, стрелочки (стадии)
20

21. Метод системной инженерии
21

22. Основы системной инженерии
• OMG «Essence -- Kernel and Language for
Software Engineering Methods» (ожидаем:
февраль 2013)
• Основы – сущности и язык для методов
программной инженерии
• Консорциум SEMAT (http://semat.org)
• Организовано Русское отделение SEMAT
• Ситуационная инженерия методов (OMG
SPEM 2.0, ISO 24744)
22

23. Язык, сущности, практики
Сущности Практики
Язык (абстрактные) (конкретные)
...
...
23

24. Как дела?! Чеклисты.
• Отражают не всё, а только главное (что
все знают, но почему-то забывают и
игнорируют).
• чеклист запуска двигателя в полёте: 1. Fly the
aircraft!
• Прогон в специальных паузах (pause
point) перед началом или перед
окончанием каких-то работ
(обнаружить проблемы, пока не
поздно, гарантировать их
обнаружение!)
• Обязательно вслух перед всеми
(общее знание проблем)
• Проблемы находятся только 1 раз из
10. Этот один раз полностью окупает
все затраты на остальные десять.
24

25. Альфа: состояния = чеклисты : чекпойнты
ALPHA -- Abstract-Level Progress Health Attribute.
25

26. Деятельность меняет альфы
Дела меняют рабочие продукты
меняет состояния
продвигает
описывает
меняют детальность
26

27. Альфы инженерного проекта
27

28. Области интереса
инженерной компании
• Основная деятельность
• Клиент (возможности,
заинтересованные стороны):
маркетинг
• Решение (требования, системная
система): инженерия инженерия
• Предпринятие (работы, люди,
технологии): операции
• Организационно-техническое развитие
предпринятия
• Стратегирование
• Организационная инженерия
• Ведение проектов развития
28

29. Деятельности и компетенции
инженерного проекта
29

30. Essence и ISO 15288:2008
30

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