[БЕЗ СЛОВ] А

сейчас мы с вами познакомимся

с основными видами жизненных циклов.

В принципе, их бесконечное число.

Вы можете взять какие-то практики, сказать, что они примерно так вот в жизни

будут использоваться, вот принципиальная схема, как мы будем работать.

И я просто дам вам некоторые иллюстрации того,

что речь идёт о принципиальных схемах.

Самая верная, когда вы видите принципиальную схему,

и вы помните, когда мы рассматривали принципиальные схемы радиотехнические,

пневматические, софта, компонентные диаграммы — мы видели,

что они устроены не так, как модульное описание,

где всё-таки больше какие-то таблички, какие-то перечисления,

потому что в принципиальных схемах важны связи, важен показ того, как разные

части связаны друг с другом, какие роли они по отношению друг к другу выполняют.

С жизненным циклом то же самое.

Если вы видите старый жизненный цикл, то, скорее всего,

это будет такая колбаска, в которой вы видите части.

Если вы видите вид жизненного цикла, то есть современное представление,

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

Самый первый вариант, и он самый популярный до сих пор,

когда люди отказались от этой колбаски,

это когда колбаску просто взяли и её согнули буквой V латинской.

И получили так называемую V-диаграмму.

Вот вы видите типичную V-диаграмму.

Вы видите, что там логическое время после этого, а не физическое,

и это самая распространённая схема для описания системной инженерии.

Мы увидим там очень много слов, которые мы проходили порознь,

но вы сейчас их увидите все эти слова на одной картинке.

Итак, вы видите, что левая часть диаграммы называется System definition.

Почему?

Это V нисходящая часть.

System definition, потому что мы не работаем с веществом.

Мы просто определяем систему.

Мы строим различные описания системы.

Означает ли это, что в физическом времени мы не будем работать с веществом?

Нет, потому что речь идёт только о принципиальной схеме,

мы ничего не говорим, что будет в реальном мире, в реальной ситуации.

Мы говорим, что логическое время,

в логическом времени мы всё-таки сначала определяем, что мы делаем, а потом делаем.

Что такое делаем?

Мы работаем с веществом, грубо говоря,

работа с битами превращается в работу с атомами, и это System realization.

Это правая часть диаграммы.

Но в system realization после того, как сделана система,

далее идёт system operation, иногда её показывают, иногда её не показывают.

Правильно показывать, что ещё есть вывод из эксплуатации — System retirement.

Но хотя бы давайте покажем system operation, и у нас тогда не просто V,

а что-то типа корня квадратного, где горизонтальная черта —

это будет означать, что система сделана и она в работе.

Она in operation.

Она функционирует.

Для чего потребовалось перегибать вот так линию времени?

Как всегда нам не хватает выразительных средств одномерной диаграммы для того,

чтобы показать связи во времени, и мы переходим тогда к логическим рассуждениям.

Мы понимаем, что принимается в эксплуатацию та система,

у которой определены потребности.

Та система, которая удовлетворяет потребности.

И самая верхняя линия, вы видите, оранжевая — это линия валидации.

Или линия приёмки.

С другой стороны, мы понимаем,

что после определения потребности там может быть работа с требованиями,

там будет архитектурное проектирование, там будет рабочее проектирование.

Обратите внимание, это всё практики, то есть это деятельности,

которые выполняются в той или иной части видеограммы.

И то же самое в нижней части System realization вы видите изготовление,

далее выше идёт интеграция.

И мы понимаем, что интегрируются те части системы,

то есть буквально собираются, в единое целое интегрируются,

которые были запроектированы в рамках архитектурного проектирования.

И идёт проверка, то есть верификация.

То же самое, когда мы изготавливаем отдельную небольшую деталь, мы понимаем,

что вот она изготовлена, а вот рабочее проектирование, рабочка, чертежи рабочие

какие-то или рабочие информационные модели с точностью, достаточной для

изготовления; и речь идёт о том, что мы то, что изготовили, обязательно проверяем.

Вот для показа вот этих вот отношений проверки и приёмки, собственно,

и была придумана эта форма V.

На этой же диаграмме мы видим, что есть линия горизонтальная,

пунктирная линия, на которой обычно показывается работа инженеров по

специальностям разным: механика, электроника, программная инженерия.

И мы видим работу архитекторов, то есть тех, кто занимается системой в целом.

То есть это архитектурное проектирование, это работа с требованиями.

Тут, конечно, абсолютно не все практики указаны.

Практики указываются самые разные, в зависимости от того,

какой у вас интерес сейчас обсуждается.

Но обратите внимание на эту форму.

Он бывает очень разной, её и объёмной рисуют, и рисуют не V, а W,

такой забор иногда даже рисуют, рисуют разные высоты, что мы работаем с...

Начальнику показываем только то, что сдаётся в эксплуатацию,

но внутри себя мы иногда несколько раз работаем с определениями,

а потом реализуем определениями, реализуем итерациями между собой в команде проекта.

То есть очень разные формы.

Но запомнили, вот так вот она выглядит.

Тем не менее, я хотел бы показать вам

ещё один вариант и сказать основную мысль современной системной инженерии.

Каждый раз, когда у вас есть хотя бы 1 рубль, который вы можете потратить не на

System realization, а потратить на System definition, то этот рубль потраченный

экономит 10, 20, 30 рублей в System realization.

Когда вы можете месяц лишний попроектировать атомную станцию, и этим у

вас будут заниматься 200 человек, то вы можете сэкономить 2 дня работы, например,

стройки, на которой будет 2 тысячи человек плюс омертвлённых на несколько

миллиардов долларов активов, потому что станция в этот момент не будет работать.

А вы просто на два месяца задержите эту стройку.

Так вот мне кажется,

что это главное положение системной инженерии, которое сейчас отрабатывается.

Это вот тот ход,

который системные инженеры говорят: ход на модель-ориентированную

системную инженерию, что давайте работать с моделлерами.

И модели, сначала вот станцию будем собирать в виртуальном пространстве,

сначала самолёт у нас будет летать внутри компьютера,

сначала мы будем любой наш объект строить внутри компьютера как можно более

детально, а потом мы будем изготавливать.

Итак, лозунг появился: с первого раза правильно.

И первый самолёт вот сейчас летает.

Первая ракета, которую вы делаете, она долетает до цели.

Я уже говорил, что в Индии «Орбитер»,

который полетел на Марс — это первая ракета,

которая с первого раза достигла цели, с первого раза миссия была выполнена.

Почему?

Ровно за счёт вот этого компьютерного моделирования.

И вы видите ту же самую видеограмму,

в которой System definition просто вот такая толстенькая.

И вы видите дополнительные стрелки верификации и валидации, потому что они

показывают, что вы верифицируете не то, что вы изготовили, и валидируете,

а вы верифицируете и как-то валидируете всё ещё в моделях.

То есть вы уточняете и уточняете, увеличиваете и увеличиваете число моделей,

но в какой-то момент вам надо проверять, как эти модели соответствуют друг другу.

Вот вы этим и занимаетесь, вы проверяете.

Поэтому у нас добавилось число этих стрелочек.

Надо запомнить, что время на этих диаграммах абсолютно условное,

что это не колбаски, это не развёртки во времени.

Вы понимаете, что жизненный цикл и вид жизненного цикла — это архитектурное

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

только то, что если вы меняете что-то указанное вот в этих диаграммах,

то вам придётся переделать всё остальное.

Но не то, что вы поменяли какую-то мелкую практику, никто даже не заметил,

что вы забиваете гвоздь молотком, который держите в левой руке, а не в правой руке,

у вас там ничего не поменялось.

Только высокоуровневая.

Время если вы хотите реальное смотреть,

то вам надо смотреть совершенно другие диаграммы.

Вам надо смотреть диаграммы в системах управления проектами, трекере,

в календарях.

В этих диаграммах вы не сможете посмотреть реальное время.

Кто выполняет роли, какие там задействованы ресурсы,

тоже вы не увидите в этих диаграммах.

Обычно тут только практики, и вам надо смотреть на каких-то модульных диаграммах,

где будет сказано, что службы такие-то работают с такими практиками,

а подразделения такие-то с такими практиками.

Это всё в других местах.

Я просто хочу сказать, что речь идёт о исключительно

системах организации деятельности, которые понимаются в разрезе дисциплин,

и только отчасти поддерживающих их технологию.

Вот на этих диаграммах в основном практики именуются по дисциплинам,

и говорится, какие именно дисциплины,

с какими дисциплинами работают люди в той или иной деятельности.

А вот вы видите еще одну видеограмму,

но вот очень привычная такая вот схемка, и тут я еще раз хотел бы сказать про то,

как делаются эти схемки из альф в стандарте 42010.

Там определено два метода, каким мы строим описание системы,

полное из частных описаний системы, соответствующих удовлетворению какому-то

одному интересу, какому-то одному методу описания.

У вас есть метод прожекторный, и есть метод синтетический.

Синтетический метод такой, что мы делаем какие-то описания,

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

мы просто собираем все эти листочки или базы данных,

или информационные модели и просто говорим, что «Смотри, вот эта модель,

вот этот элемент модели соответствует вот этому элементу другой модели,

а вот этот элемент какой-то модели соответствует вот этой модели».

Это соответствие указывается, correspondence, что чему соответствует.

А есть другой метод, он называется прожекторный.

Речь идет о театральном прожекторе.

В театральном прожекторе у нас одновременно и синий, и зеленый,

и красный цвета, но на самом деле там белый цвет, там есть все цвета, и

есть фильтр, который показывает нам только то, что нам надо видеть в данный момент.

Вот мы в нашем курсе работаем более-менее с прожекторным описанием.

Мы считаем, что у нас как будто бы есть одна такая большая-большая-большая

диаграмма, в ней представлены все связи, в ней представлены все элементы,

и мы каждый раз на диаграмме просто показываем,

как вот в театральном прожекторе, только отфильтровываем то, что нам надо.

Вот сейчас вы видите из нашего курса некоторый набор понятий,

мы отфильтровали его и показали в виде той же самой V.

Мы видим system realisation, мы видим system definition.

Но мы показываем немножечко раскрытое по разным практикам,

поскольку V работает с практиками, разные объекты, разные альфы,

с которыми работают разные практики.

Мы видим, что у нас есть возможности, и с возможностями у нас связана

использующая система, и поэтому мы видим,

что потребности стейкхолдеров у нас привязаны к возможностям.

Стейкхолдеры обеспечивают нам возможности.

И мы видим от system realisation линию валидации как раз к потребностям системы.

А дальше возможности фокусируют требования.

«Фокусируют» это означает, что уже не любые требования мы можем придумывать из

головы, мы можем выявлять те требования, которые соответствуют

наилучшему удовлетворению потребностей стейкхолдеров.

Опять же, когда мы сработались с требованиями,

у нас есть системные требования, требования уже к целевой системе,

мы можем определять в логическом времени архитектуру.

И архитектура то же самое,

фокусируется требованиями, особенно архитектурными требованиями,

то есть некоторые требования существенно влияют на выбор архитектурных решений.

И с другой стороны, архитектура у нас фокусирует рабочие описания,

то есть те описания, non-architectural part of design, те описания,

которые достаточны для того, чтобы изготовить нашу систему.

И все это system definition, все это входит составной частью в system

definition, и вы видите в system realisation, что есть вся система в целом,

есть какие-то крупные подсистемы и есть какие-то мелкие части, например,

детали, в которых уже вот нет отдельно изготавливаемых частей,

из которых надо собирать, например, цельнолитая какая-нибудь деталь.

И вот вы видите вот эту диаграмму,

диаграмма складывается в форму V, и то же самое,

вот наверху вы видите фрагмент, я анонсирую,

буквально будет в следующем модуле у нас системная схема проекта.

Вы видите, что system realisation и system definition, вот эту пару,

которую вы видели во многих диаграммах, она тоже присутствует на этой диаграмме.

Только единственное то, что на этой диаграмме показано,

что требование архитектуры, неархитектурная часть дизайна внутри V,

вы могли бы убрать, как бы отфильтровать еще и system definition,

но я для красоты и для пущей понятности пририсовал это сбоку от чистой V.

А вот еще один вариант — верификация и валидация.

Это V от Министерства обороны США.

Та же самая идея.

Вот слова according to это как раз и означает, что «в соответствии с»,

то есть речь идет о проверках, о приемках.

Говорится о том,

что вы должны проектировать сначала всю систему в целом на верхнем

уровне и в конце концов изготавливать эту всю систему на верхнем уровне.

А с другой стороны вы должны делать то же самое на уровне подсистем, проектировать

отдельные подсистемы после того, как вы разбили на части эту систему, приняли

архитектурное решение, и, соответственно, собирать эту систему на уровне подсистем.

И так далее, пока вы не дойдете до самых-самых маленьких деталей,

которые вы каждую из них тоже проектируете, изготавливаете,

и тем самым у вас получается вот эта вот буква V.

Запомнили: V-диаграмма, она одна из основных в системной инженерии,

которая позволяет логически обсуждать, что вы вообще делаете в вашем проекте.

V-диаграмма и её примеры

Системное мышление

Meet the Instructors