Восьмая лекция курса "Введение в системную...
DESCRIPTION
TRANSCRIPT
![Page 1: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/1.jpg)
Лекция 8«Введение в системную инженерию»
МФТИ, Долгопрудный8 апреля 2012г.
![Page 2: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/2.jpg)
2
Реализация системы(вынос в реальность)
• Изготовление• Интеграция• Верификация• Валидация• Передача в эксплуатацию
• Эксплуатация• Вывод из эксплуатации
![Page 3: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/3.jpg)
3
Verivication & validation
The Vee Activity Diagram (Prosnik 2010) Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). – из SEBoK v0.71http://www.sebokwiki.org/075/index.php/System_Realization
![Page 4: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/4.jpg)
4
Целеориентированная инженерия требований и инженерные обоснования
(http://ailev.livejournal.com/811715.html)
• Общие корни: логика• GORE – “motivation” (ArchiMate, OMG BMM)• Assurance case (GSN, CAE)• Design rationale
Нет требований – нет обоснований!
![Page 5: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/5.jpg)
ISO 15026, assurance case
• Ведется инженерами в обязательном порядке• Документирует степень, в которой предполагается удовлетворить требования на
текущий момент• Документирует методы, которыми планируется решить известные на данный
момент проблемы• Используется менеджерами в моменты принятия решений о дальнейшем
выделении ресурсов (decision gates, anchor points), чтобы увериться в приемлемости рисков перехода на следующую стадию
• Метафора – «судебное дело» (при пересмотре выделения ресурсов происходит «доказательство приемлемости риска»).
• Обязательность независимой от разработчиков проверке доказательства приемлемости рисков
• Составляется по особым правилам (декларации достижимости требований, аргументы в поддержку деклараций, документальные подтверждения аргументов)
• Требования к формулировкам (ясность, однозначность...)• Различный поддерживающий софт
5
![Page 6: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/6.jpg)
6
Assurance case
![Page 7: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/7.jpg)
Ошибки рассинхронизации менеджерской и инженерной работы
• не включают обоснование реализуемости для проекта целиком на уровне промежуточных уровней описания. При выполнении практики Интеграция (изготовление, сборка, наладка) получают много сюрпризов по нестыковкам, объем переделок становится огромным -- время и бюджет увеличиваются в разы.
• проект планируют так, чтобы у исполнителей не было запасов времени между работами (приоритет загрузки ресурсов). Это имеет сразу два негативных последствия: случайные отклонения в отдельных работах невозможно скомпенсировать (все задержки будут просуммированы, и на это время задержится весь проект), также невозможно будет правильно спланировать промежуточный межстадийный пересмотр выделения ресурсов -- решение о выделении ресурсов можно будет принимать только по небольшим работам, но не по всему проекту в целом. То есть пересмотреть проект при таком подходе будет невозможно: пока пересматриваешь один ручеек этой речки, другие ручейки уже убежали.
• "недопересмотры" и "псевдопересмотры" -- когда решение по выделению ресурсов по факту не может быть принято, но любое частное решение по какой-нибудь гаечке оформляется как полноценный пересмотр всего проекта. В тот момент, когда проект заходит в тупик, уже нет способов планово организовать принятие полноценного корректирующего решения по всем работам проекта -- только "авральные" внесистемные, внепроцедурные, внерегламентные.
• слишком мало стадий в высокорисковых больших проектах: например, пересмотр выделения ресурсов случается в самом начале проекта, а затем только при передаче в эксплуатацию (через 5-10 лет после принятия решения о старте проекта -- проект ведь может быть очень большой!), затем сразу в момент вывода из эксплуатации (через десятки лет). Нельзя удивляться, что весь проект проходит в непрерывных авральных совещаниях по переделкам на всех стадиях, но эти совещания мало меняют ход проекта: принятие решений по отдельной параллельной струйке в речке ведущихся работ мало влияет на течение других струй. А интегрирующую задвижку на всю речку ведущихся работ просто не предусмотрели, поэтому о речке в целом мало кто думает (знаменитое "к пуговицам претезний нет?") -- отсюда и огромное число переделок в таких недосинхронизированных, недопересмотренных проектах.
• при пересмотре выделения ресурсов не меняют требования, хотя и корректируют выделяемые ресурсы. Требования тоже нужно менять, утверждая под свежевыделенные ресурсы новые требования. Для этого, конечно, доработка требований должна входить в работы предыдущей стадии.
ISO 15288 не дает практик того, как этих ошибок избежать. Этот список можно продолжать и продолжать, но все эти ошибки подробно разбираются в рамках конкретных методов
разработки (ICM, RUP, DSDM, OpenUP, spiral model и т.д.). Правда, в каждом методе обсуждается только класс "любимых" для этого метода ошибок, и игнорируются другие.
7
![Page 8: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/8.jpg)
Выбор вида жизненного цикла• Вид (форма) жизненного цикла, метод (методология) разработки, процесс
разработки (например, software process) – способ связи инженерных практик (разработка сверху-вниз, снизу-вверх, изнутри-наружу и т.д.) и менеджерских (пошаговое выделение ресурсов, контроль времени).
• Общая дискуссия: «водопад» против «гибкости» (заранее написанные ноты против импровизационного джаза).
• Существует множество методов управления ЖЦ/разработки:– Rational Unified Process (RUP), – OpenUP, – Dynamic Systems Development Method (DSDM), – eXtreme programming– …
• ISO 15288 никак не проясняет предпочтений к форме ЖЦ, форме разработки или методу управления ЖЦ, но указывает на необходимость иметь описание ЖЦ.
• Для описания ЖЦ нужно мыслительно породить и затем документировать его экземпляр (т.е. продумать проект). Нельзя избежать выбора вида жизненного цикла/методологии разработки.
• Наш выбор – метод постадийного выделения ресурсов (ICM), дающий максимальную свободу для выбора инженерных практик и их связи с потребностями менеджеров в контроле хода работ. 8
![Page 9: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/9.jpg)
Метод постадийного выделения ресурсов
• Incremental commitment model (ICM)• Метод управления жизненным циклом• опыт множества предыдущих поколений разных методов
УЖЦ (главным образом – используемых министерством обороны США, т.е. крайне разнообразных).
• Разработка метода поэтапного выделения ресурсов финансировалась DoD, поэтому все тексты существенно ссылаются на требования положений документа DoDI 5000.02 к методам управления жизненным циклом. Отсюда в текстах ICM регулярно путаются «отрасленезависимая» терминология самого ICM и терминология ВПК США типа "milestone A". Но это неважно, сам ICM независим от требований DoD и может быть использован в любых проектах.
• Автор – Barry Boehm (он же автор «спиральной модели», первым указавший на необходимость итераций практик в рамках разработки).
• «Генератор» разных форм ЖЦ – в зависимости от паттерна рисков проекта
• Дает ответы на вопросы об ошибках координации работ менеджеров и инженеров (дополняет ISO 15288)
9
![Page 10: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/10.jpg)
Необходимость пересмотров выделения ресурсов: стык мендежерских и инженерных решений
• Теоретический смысл обязательного включения работы по пересмотру выделения ресурсов между всеми стадиями заключается в необходимости периодической синхронизации параллельно ведущихся разработок.
• Вероятность того, что трудности возникнут при стыковке готовых ("в металле", "в бетоне", "в коде" и даже "в голове" для человеко-системной интеграции) частей системы очень велика, поэтому эта стыковка-интеграция должна проходить не однократно в момент окончания стадии интеграции (изготовления, сборки, наладки) и начала стадии эксплуатации, а существенно чаще, для чего предусматривается несколько пересмотров выделения ресурсов.
• Решение по продолжению работ должно делаться на основании целостного описания, а не на основании разрозненных нестыкуемых между собой разной степени проработанности сведений о системе.
• Пересмотр выделения ресурсов = decision gate• Пересмотры выделения ресурсов требуют специальных артефактов:
• 1. описание жизненного цикла (определяет моменты пересмотра), • 2. требований к результатам следующей стадии, и • 3. инженерного обоснования (assurance case, доказательства приемлемости рисков
перехода к следующей стадии) 10
![Page 11: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/11.jpg)
11
ICM Ancor Point Reviews
Guide for Using the Incremental Commitment Model (ICM) for Systems Engineering of DoD Projects Version 0.5
![Page 12: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/12.jpg)
12
Генератор видов ЖЦ по профилю рисков
![Page 13: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/13.jpg)
How to integrate all these meta(models)/(meta)data?
13
From FutureModels presentation
![Page 14: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/14.jpg)
14
ISO 15926 и жизненный цикл
![Page 15: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/15.jpg)
15
ISO 15926 и жизненный цикл
![Page 16: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/16.jpg)
16
Организация зачётаИтоговая работа выполняется в форме подготовки эссе, в свободной форме описывающий системную инженерию простых объектов (на бытовой и учебной тематике). Ожидаемый объём эссе – не менее трех страниц текста. Выполнение итоговой работы требует порядка трех-четырех часов времени студента.В эссе студент должен продемонстрировать владение терминологией системной инженерии, а также понимание основных практик системной инженерии и умение адаптировать типовой жизненный цикла к конкретной целевой системе. Студенту предлагается выбрать для эссе одну из следующих систем/сервисов:
• семейный обед• домашнее животное (кошка, собака, морская свинка – наиболее знакомое)• поддержка чистоты квартиры• домашний компьютер• супружество• физический эксперимент• лекция про системную инженерию в физ-матшколе• реферат• экзамен учебной сессии• подготовка текста настоящего эссе• целевая система, разрабатываемая базовой организацией студента
![Page 17: Восьмая лекция курса "Введение в системную инженерию"](https://reader034.vdocuments.site/reader034/viewer/2022052618/548d4496b47959be778b45de/html5/thumbnails/17.jpg)
17
Спасибо за вниманиеАнатолий Левенчук,Директор по исследованиям Русского отделения INCOSEhttp://[email protected]
Виктор Агроскин[email protected]
TechInvestLab.ru(495) 748-53-88