[БЕЗ_ЗВУКА] Так появилось понятие жизненного цикла. Мы начали с ним работать. У нас появилось время, и у нас появилось описание тех проектов, которые работают с нашей системой, то есть описание систем деятельности и жизненный цикл как описание не самой системы, а системы деятельности вокруг системы. Очень хорошо в этот момент мы прибавили фактически вторую половину системного мышления. У нас системы деятельности начали рассматриваться совместно с рассмотрением чисто инженерно целевой системы, у нас там появились какие-то менеджеры, появились люди, которые заняты другими людьми, а не только своей целевой системой. У нас появилось рассмотрение обеспечивающих систем или одной большой обеспечивающей системы. И, казалось бы, все хорошо, если бы не проблемы. Первая проблема — у нас как-то в жизни выродилась стадийность. Если мы писали раньше, что систему замысливают, что ее разрабатывают, проектируют, потом изготавливают и так далее по жизненному циклу, то сейчас мы не можем так говорить, потому что распространилась параллельная инженерия — concurrent engineering. Мы одновременно замысливаем; одновременно прикидываем, как бы эту систему разработать; одновременно пытаемся разработать — особенно то, что разрабатывать очень долго; одновременно изготавливаем, например, роем котлован, еще не зная даже, сколько точно этажей будет у здания, потому что не успеем же. Так и говорят: требования рынка. Мы должны всё как можно быстрее выносить на рынок. И вот это «как можно быстрее» приводит к тому, что у нас встроенный проект с этими стадиями превращается в проект. Мы в него входим. Все стадии вместе, «винегретом» вот так, ну и выход из проекта. И требования делаем до конца, все делаем до самого конца. Как только мы это признали, у нас проблема. Мы эту «колбаску» с секциями строгими не можем рассматривать, мы не можем рассматривать это строго проектно. И мы при этом понимаем, что кроме «гейтов» — ворот, где мы принимаем решение идти — не идти дальше, например, замыслили — не замыслили, «гейт». Если плохо замыслили, прекращаем проект. Хорошо замыслили — отлично, идем дальше. Разработали — не разработали. Ворота опять ставим. Открываем ворота или не открываем? Go — no go решение, идем — не идем. Если плохо разработали, то ничего не изготавливаем и, например, прекращаем проект либо возвращаем в разработку. Были «гейты». Сейчас мало того, что мы избавляемся от «гейтов», потому что никто никого не ждёт — у нас параллельная инженерия, но еще и нужны содержательные контрольные точки. А что за контрольные точки у нас внутри разработки? Какие там требования предъявляются? Можем ли мы отследить содержательные моменты, а не только вот эти формальные моменты, связанные с разработкой? То есть там множество содержательных моментов. И тем самым мы приходим к необходимости как минимум двумерного отображения. У нас появляются промежуточные формы. И вот rational unified process — такой рациональный унифицированный процесс разработки. Ивар Якобсон его придумал, и фирма IBM его продвигала, где Ивар Якобсон работал. Вы видите это на картинке — так называемую Hump Diagram, то есть горбатая диаграмма, которая отражает вот эти неудобства. Во-первых, прежде всего, мы видим всё то же самое, мы видим фазы — это стадии жизненного цикла. Мы видим, что система — inception, она зачинается. После этого она разрабатывается — elaboration, то есть с ней происходит какое-то вырабатывание, отработка. После этого она конструируется. После этого мы видим, она передается в эксплуатацию — transition. И далее это, конечно, не совсем системное инженерное полное рассмотрение, не совсем система менеджерская, потому что тут часть жизненного цикла, эксплуатации и вывода из эксплуатации нет. Это только связано с разработкой и чуть-чуть передачей в эксплуатацию, с одной стороны. Мы видим тут стадии жизненного цикла, мы видим тут итерации, которые признают то, что мы работаем как-то вот безымянно. То есть вот стадии жизненного цикла тут более мелкие какие-то единицы вводятся. Они связанные со временем. Но это всё сборочное представление. То есть по горизонтали идет сборочное. Самое интересное — по вертикали. По вертикали мы понимаем, что там есть некоторые виды работ. Виды работ, смотрите, я говорю о чем-то функциональном. Тут они именованы дисциплинами, например, бизнес-моделирование. Помним, что бизнес заменяется словом «организационное». Поскольку это для корпоративного софта, мы делаем организационное моделирование. Потом мы работаем с requirements — с требованиями. Смотрите, потом это тоже условное. Далее мы обязательно занимаемся анализом и проектированием. Потом мы занимаемся реализацией — implementation, потом тестируем, потом разворачиваем. И смотрите, получается очень странно. Я говорю о каком-то времени по вертикали. В этот момент по горизонтали у меня тоже время. И вот это двумерное временно-временное представление является таким очень странным представлением. Горбы означают то, что я занимаюсь организационным моделированием фактически все время проекта. Я занимаюсь требованиями все время проекта, только акценты другие. Максимум работы в самом начале по бизнес-моделированию, по организационному моделированию. В конце совсем чуть-чуть. А вот, например, разворачивание системы, вы видите, в начале практически оно не происходит. А в конце я довольно много занимаюсь в команде вот этими процессами разворачивания системы. Так что же это за такие времена? Да, у нас есть логические времена, у нас есть роли, у нас есть функциональные какие-то дисциплины, как их поименовал Якобсон. Там слово «дисциплины», и мы занимаемся какими-то деятельностями в каком-то порядке. Причем деятельности все вместе — это такое логическое разбиение. То есть у нас опять появляются функциональные объекты, которые переносят знания о той системе деятельности, которая занимается разработкой в данном случае программной корпоративной системы. А вот там, где написано «фазы» или «стадии жизненного цикла», там у нас сборочная диаграмма, которая показывает во времени различные стадии, различные работы, разных исполнителей, которые будут потом заниматься этими деятельностями, как они соединяются во времени, как они собираются во времени. Итак, у нас есть два представления. С одной стороны, у нас есть представление конструктивное во времени. С другой стороны, функциональное. Знакомый всем случай. То есть если мы берем обеспечивающую систему, то мы можем рассматривать жизненный цикл 2.0. Он указывает на деятельность, то есть на набор практик, на функциональные объекты по созданию успешной системы. То есть отвечает на «как работает», а вместо стадий, «как собрать», жизненного цикла он указывает на какие-то архитектурные решения о последовательности использования практик во времени. И вот это вот представление жизненного цикла 2.0, где деятельность — это главное, а стадийность не главное, это дела последних, ну скажем так, пяти, может быть, шести лет. Потому что до этого жизненный цикл был 1.0 — это был проект, и сейчас он используется. Обратите внимание, как резко меняется форма диаграммы. Первичны практики. Дисциплины — что вы делаете, а не когда вы делаете. А когда вы делаете? Вы все время делаете одно и то же, и это показано на так называемой спиральной диаграмме, спиральный вид жизненного цикла, когда написано, что вы на каждом витке делаете одно и то же, только каждый раз более детально, точно, иногда отменяя, иногда на прототипа, приближаясь и приближаясь к окончанию этой всей работы. То есть вы проходите разработку, а потом, может быть, и эксплуатацию одновременно, продолжая разрабатывать модификации. И вы работаете по спирали. Вот так вот деятельностно выглядит фактически любая диаграмма. Смотрите, другая форма диаграммы, тут нет такой явной линии времени. Вы видите спираль. И считается, что все остальные виды жизненного цикла, слова «вид жизненного цикла» четко обозначают то, что вы рассматриваете деятельностную сторону практики, как составлены разные функции. Функции чьи? Функции обеспечивающей системы по отношению к целевой системе. Функции ее. Вот это все жизненный цикл 2.0. Итак, жизненный цикл — это набор компонент (прежде всего, функции, логические единицы, альфы) обеспечивающей системы как культурно обусловленной деятельности. И считается, что это повторяется, что мы имеем какой-то паттерн, то есть мы можем взять в культуре какие-то виды жизненного цикла. И это инженерный интерес. Нам надо узнать, как работает вот в тот момент, когда обеспечивающая система работает, почему она достигает своей цели. Мы объясняем, как она работает. Мы ее чиним, налаживаем. И второй интерес — это интерес менеджерский: как сделать, как взять людей, ресурсы, модули, подразделения какие, какие организации выбрать, какие работы они в 4D выполняют, какие задачи решают, физические единицы, рабочие продукты. То есть это проект или процесс, который наряду с компонентами тоже представлен в жизненном цикле 2.0. Но акцент теперь делается не на вот эту рабочую составляющую, а на функциональную. Поскольку мы думаем об обеспечивающей системе как о системе, мы понимаем, что она определяется в функциональной действительности прежде всего и только потом в действительности модульной. Жизненный цикл системы вы видите. Вот он — четырехмерный этот червячок. Главная стадия в нем — стадия эксплуатации. И мы понимаем, что обеспечивающих систем либо одна как бы на всех — вот мы ее мысленно представляем, — либо их много. Может, тут не совсем удачно пример взят нетехнический, а системы живой, потому что, может быть, тут вот кто-то будет видеть живой жизненный цикл. Но это чисто для иллюстрации. Вот мы имеем человека, семья его создает на одной стадии, обеспечивающая система — училка — его учит. Далее он самопринадлежен, он сам себя эксплуатирует, Смотрите: нет обеспечивающей системы, которая его эксплуатирует, он сам себя эксплуатирует — вот тут вот отличие. В других случаях будут системы, которые его эксплуатируют. Иногда может не быть. Тем не менее вот выделенная стадия — эксплуатация. Ради нее все создается. После чего мы имеем доктора, который обеспечивает работу этого человека. Дальше человек этот уже не работает, не эксплуатируется. После чего микробы завершают существование человека, потому что в нашем случае совершенно не важно, что там происходит дальше — мы продолжаем работать с человеком как с физической сущностью. И мы понимаем, что микробы в данном случае — обеспечивающая система. И мы видим полный жизненный цикл от самого замысла этого человека до самого последнего, последней частички, разлагаемой микробами, пока эта система не вышла в существование. Мы видим, что в 4D-пространстве она представлена. И как мы его обсуждаем, этот жизненный цикл? Буддисты отдыхают. Мы обсуждаем жизненный цикл сразу в трех временах. Первое время, главное — это время эксплуатации. Оно может идти, например, если наша система должна взорваться — скажем, 200 миллисекунд. Или если это компьютерная программа, это может быть целых 2 секунды. Тем не менее у нас главное время — это время эксплуатации нашей системы, оно скрыто будущем. И мы видим вот эксплуатацию. И мы понимаем, что второе время мы должны рассмотреть — возможно, несколько лет разработки этого продукта: Вот с самого начала этой разработки, замысла, до вот исключения из жизни вот этой нашей системы, до вывода из эксплуатации. И третье время — вот я сейчас обсуждаю, мы обсуждаем жизненный цикл, мы обсуждаем эксплуатацию, мы обсуждаем эту систему, — это то время, в которое мы прямо вот сейчас работает, это здесь и сейчас. Оно называется методологическое время. Почему методологическое время? Потому что время жизненного цикла, оно же в 4D, оно одновременно представлено — видите, по горизонтали я вижу и раньше, как это было, вот этот временной червяк, и как это потом будет, то есть мы видим одновременно все это время. А здесь и сейчас через нас проходит время, это физическое время как бы за пределами вот времени жизни системы, вот мы его рассматриваем, методологическое время. Опасно рассматривать жизненный цикл системы, вообще системы и все остальное, когда линия времени проходит через нас, когда мы видим вот только то, что происходит сейчас, и это заслоняет то, что в будущем будет — мы не видим по жизненному циклу, что там будет дальше, мы не видим того момента, как система эксплуатируется. В конструкторских бюро это очень часто. То есть мы видим только сиюминутные сейчасные интересы. И мы не можем учесть то, что было, когда эту систему стейкхолдеры хотели, когда эта система замышлялась, потому что оно сзади. Сзади глазков нету, и поэтому мы понимаем, что мы теряем связь с началом жизненного цикла. Вот это самое страшное — думать о жизненном цикле только здесь и сейчас, как этого от нас требуют всякие психологи. У инженера мышление должно быть устроено много сложнее, он должен думать одновременно о трех временах.
