Тьюториал«Введение в системную инженерию»

Москва15 января 2012г. (второй день из трёх)

Жизненный цикл системы• Всегда полный (в отличие от ЖЦ проекта)

• Стадии – отрезки времени, границы по смене главной инженерной деятельности (cognitive framework)

• Система – отнюдь не всегда «времени эксплуатации»!!!

2

замысел прекращение существования

t

3

Разнообразие типовых жизненных циклов(природы системы, стадий жизненных циклов, инструментов)

Софт Концепция Разработка Поддержка Списание

Система Идея Разработка Изготовление Использование Поддержка Списание

Оборудование Идея Проектирование ИзготовлениеЭксплуатация и

поддержкаСписание

ПерсоналОпределение

требуемых

компетенцийПриобретение Обучение

Использование

и ростОтставка

Здание Визуализация

Проектирование

сооружения и

площадки

Согласование СтроительствоЭксплуатация

и поддержкаРазборка

Природный

ресурсПриобретение Разработка Эксплуатация Рекультивация

ПроцессОпределение

выхода

Графическое

представлениеОписание

Пилотное

внедрение

Использование и

совершенствованиеЛиквидация

Жизненный цикл объектов работы (комплектующих/предметов снабжения)

IEC/EN 81346, RDS-PP, KKS

Ситуация

Объект

Спецификация функции

Спецификация компонента

Спецификация модели

Индивидуальная карточка экземпляра

Физический экземпляр

Объект «мотор»

«Мотор» в обычном языке

Реальный, функционирующий

Запланированный, историческая запись, и т.п.

Система жива, пока жива её функция! Конструкция может меняться (атомы менее важны, чем идея).

Жизненный цикл и поставки

http://www.econlib.org/library/Essays/rdPncl1.html5

Рынок как механизм согласования целей и разделения труда

Не все задачи решаются инженерно

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

6

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

7

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

9

Разнообразие интеграции данных жизненного циклав эко-системе инжиниринга

Замысел Архитектура «Рабочка» Изготовление Эксплуатация

Макро PLM1 PLM2 PLM3 PLM4 PLM5

Мезо PLM6 PLM7 PLM8 PLM9 PLM10

Микро PLM11 PLM12 PLM13 PLM14 PLM15

Нано PLM16 PLM17 PLM18 PLM19 PLM20

10

Специализация/профессионализация: в каждой клеткеИнтеграция в продукте: вся таблица (эко-система!)

уровни структуры вещества * уровни воплощения

КРУПНЫХ ПРОЕКТОВ С ОДНОЙ PLM НА ВСЕХ – НЕ БЫВАЕТ!ДВЕ РАЗНЫХ УСТАНОВКИ PLM одного вендора – РАЗНЫЕ УСТАНОВКИ!

PLM нуждается в интеграционном решении!

ICM Ancor Point Reviews

11

Guide for Using the Incremental Commitment Model (ICM) for Systems Engineering of DoD Projects Version 0.5

Минимум: инженерия и операции(рис.17 из ISO TR 19760)

В тексте путаются enterprise view и management view 12

[менеджерская]

Ошибки рассинхронизации менеджерской и инженерной работы

• не включают обоснование реализуемости для проекта целиком на уровне промежуточных уровней описания. При выполнении практики Интеграция (изготовление, сборка, наладка) получают много сюрпризов по нестыковкам, объем переделок становится огромным -- время и бюджет увеличиваются в разы.

• проект планируют так, чтобы у исполнителей не было запасов времени между работами (приоритет загрузки ресурсов). Это имеет сразу два негативных последствия: случайные отклонения в отдельных работах невозможно скомпенсировать (все задержки будут просуммированы, и на это время задержится весь проект), также невозможно будет правильно спланировать промежуточный межстадийный пересмотр выделения ресурсов -- решение о выделении ресурсов можно будет принимать только по небольшим работам, но не по всему проекту в целом. То есть пересмотреть проект при таком подходе будет невозможно: пока пересматриваешь один ручеек этой речки, другие ручейки уже убежали.

• "недопересмотры" и "псевдопересмотры" -- когда решение по выделению ресурсов по факту не может быть принято, но любое частное решение по какой-нибудь гаечке оформляется как полноценный пересмотр всего проекта. В тот момент, когда проект заходит в тупик, уже нет способов планово организовать принятие полноценного корректирующего решения по всем работам проекта -- только "авральные" внесистемные, внепроцедурные, внерегламентные.

• слишком мало стадий в высокорисковых больших проектах: например, пересмотр выделения ресурсов случается в самом начале проекта, а затем только при передаче в эксплуатацию (через 5-10 лет после принятия решения о старте проекта -- проект ведь может быть очень большой!), затем сразу в момент вывода из эксплуатации (через десятки лет). Нельзя удивляться, что весь проект проходит в непрерывных авральных совещаниях по переделкам на всех стадиях, но эти совещания мало меняют ход проекта: принятие решений по отдельной параллельной струйке в речке ведущихся работ мало влияет на течение других струй. А интегрирующую задвижку на всю речку ведущихся работ просто не предусмотрели, поэтому о речке в целом мало кто думает (знаменитое "к пуговицам претезний нет?") -- отсюда и огромное число переделок в таких недосинхронизированных, недопересмотренных проектах.

• при пересмотре выделения ресурсов не меняют требования, хотя и корректируют выделяемые ресурсы. Требования тоже нужно менять, утверждая под свежевыделенные ресурсы новые требования. Для этого, конечно, доработка требований должна входить в работы предыдущей стадии.

ISO 15288 не дает практик того, как этих ошибок избежать.Этот список можно продолжать и продолжать, но все эти ошибки подробно разбираются в рамках конкретных

методов разработки (ICM, RUP, DSDM, OpenUP, spiral model и т.д.). Правда, в каждом методе обсуждается только класс "любимых" для этого метода ошибок, и игнорируются другие.

13

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

14

Выбор вида жизненного цикла• Вид (форма) жизненного цикла, метод (методология) разработки, процесс

разработки (например, software process) – способ связи инженерных практик (разработка сверху-вниз, снизу-вверх, изнутри-наружу и т.д.) и менеджерских (пошаговое выделение ресурсов, контроль времени).

• Общая дискуссия: «водопад» против «гибкости» (заранее написанные ноты против импровизационного джаза).

• Существует множество методов управления ЖЦ/разработки:– Rational Unified Process (RUP), – OpenUP, – Dynamic Systems Development Method (DSDM), – eXtreme programming– …

• ISO 15288 никак не проясняет предпочтений к форме ЖЦ, форме разработки или методу управления ЖЦ, но указывает на необходимость иметь описание ЖЦ.

• Для описания ЖЦ нужно мыслительно породить и затем документировать его экземпляр (т.е. продумать проект). Нельзя избежать выбора вида жизненного цикла/методологии разработки.

• Наш выбор – метод постадийного выделения ресурсов (ICM), дающий максимальную свободу для выбора инженерных практик и их связи с потребностями менеджеров в контроле хода работ.

15

Практика постадийного выделения ресурсов

• Incremental commitment model (ICM)• Практика «управления жизненным циклом»• опыт множества предыдущих поколений разных

практик УЖЦ (главным образом – используемых министерством обороны США, т.е. крайне разнообразных).

• Разработка практики поэтапного выделения ресурсов финансировалась DoD, поэтому все тексты существенно ссылаются на требования положений документа DoDI 5000.02 к методам управления жизненным циклом. Отсюда в текстах ICMрегулярно путаются «отрасленезависимая» терминология самого ICM и терминология ВПК США типа "milestone A". Но это неважно, сам ICM независим от требований DoD и может быть использован в любых проектах.

• Автор – Barry Boehm (он же автор «спиральной модели», первым указавший на необходимость итераций практик в рамках разработки).

• «Генератор» разных форм ЖЦ – в зависимости от паттерна рисков проекта

• Дает ответы на вопросы об ошибках координации работ менеджеров и инженеров (дополняет ISO 15288)

16

Необходимость пересмотров выделения ресурсов: стык мендежерских и инженерных решений

• Теоретический смысл обязательного включения работы по пересмотру выделения ресурсов между всеми стадиями заключается в необходимости периодической синхронизации параллельно ведущихся разработок.

• Вероятность того, что трудности возникнут при стыковке готовых ("в металле", "в бетоне", "в коде" и даже "в голове" для человеко-системной интеграции) частей системы очень велика, поэтому эта стыковка-интеграция должна проходить не однократно в момент окончания стадии интеграции (изготовления, сборки, наладки) и начала стадии эксплуатации, а существенно чаще, для чего предусматривается несколько пересмотров выделения ресурсов.

• Решение по продолжению работ должно делаться на основании целостного описания, а не на основании разрозненных нестыкуемых между собой разной степени проработанности сведений о системе.

• Пересмотр выделения ресурсов = decision gate• Пересмотры выделения ресурсов требуют специальных артефактов:

• 1. описание формы жизненного цикла (определяет моменты пересмотра), • 2. требований к результатам (состояниям альф) следующей стадии, и • 3. инженерного обоснования (assurance case, доказательства приемлемости

рисков перехода к следующей стадии)

17

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

18

Дерево дел и состояний (+ обоснования)Узлы – кейсы (группы работ по достижению состояния альф)

(upper level = “mission”)

19

Vision N(World State)

• Justification 1 (Why)

• Justification 2

• Justification N

Work N(Activity)

World State N+1.1

World State N+1.2

World State N+1.3

World State N+1.N

•Justification 1

•Justification 2

•Justification N

• Sacrifice 1 (consequences)

• Sacrifice 2

• Sacrifice N

1

6

5

4

3

2

Полнота представления информации жизненного цикла

20

Колбаска, стрелочки (стадии)

V-диаграмма, горбатая диаграмма (+практики)

Карточки Основ (+ состояния альф)

... (+ обоснования)

ISO 15926

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

21

Основы системной инженерии

• OMG «Essence -- Kernel and Language for Software Engineering Methods» (ожидаем: февраль 2013)

• Основы – сущности и язык для методов программной инженерии

• Консорциум SEMAT (http://semat.org)

• Организовано Русское отделение SEMAT

• Ситуационная инженерия методов (OMG SPEM 2.0, ISO 24744)

22

Язык, сущности, практики

23

...

ЯзыкСущности

(абстрактные)Практики

(конкретные)

...

Как дела?! Чеклисты.

• Отражают не всё, а только главное (что все знают, но почему-то забывают и игнорируют).

• чеклист запуска двигателя в полёте: 1. Fly the aircraft!

• Прогон в специальных паузах (pause point) перед началом или перед окончанием каких-то работ(обнаружить проблемы, пока не поздно, гарантировать их обнаружение!)

• Обязательно вслух перед всеми (общее знание проблем)

• Проблемы находятся только 1 раз из 10. Этот один раз полностью окупает все затраты на остальные десять.

24

Альфа: состояния = чеклисты : чекпойнты

25

ALPHA -- Abstract-Level Progress Health Attribute.

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

26

меняют детальность

меняет состояния пр

од

вигае

то

пи

сывае

т

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

27

Области интереса инженерной компании

• Основная деятельность • Клиент (возможности,

заинтересованные стороны): маркетинг

• Решение (требования, система): инженерия

• Предпринятие (работы, люди, технологии): операции

• Организационно-техническое развитие предпринятия

• Стратегирование• Организационная инженерия• Ведение проектов развития

28

системная инженерия

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

29

Essence и ISO 15288:2008

30

31

Спасибо за внимание

Анатолий Левенчук,http://ailev.ruailev@asmp.msk.su(Президент Русского отделения INCOSE)

Виктор Агроскинvic5784@gmail.com

TechInvestLab.ru(495) 748-53-88