Проблемы с жизненным циклом 1.0

 

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

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

Затем появилась вообще параллельная инженерия (concurrent engineering), в которой намеренно в параллель/одновременно выполнялись работы, ранее считавшиеся строго разнесёнными по разным последовательным стадиям жизненного цикла: одновременно и велось проектирование, и изготовление системы, а какие-то неполные версии системы ещё и начинали эксплуатировать. Разговор о «стадийности» жизненного цикла всё больше и больше становился условным, а не сущностным.

Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки работ существенно сокращаются)[150]:

 

 

Во-вторых, интерфейсы между работами обсуждались с точки зрения продуктных входов и выходов, доступности ресурсов в проектном управлении. Это было очень удобно, когда речь шла о точном ответе на вопросы «когда и кем будет выполняться работа, когда она будет закончена». Но когда обсуждается, как лучше (а не как быстрее) выполнить работы, и нужно менять сами работы – информации категорически не хватало. Обеспечивающую систему нужно проектировать, как-то «изготавливать» и «налаживать» (хотя предпринятия как системы деятельности «изготавливают» и «налаживают» совсем другими методами, чем программные и аппаратные системы).

Сейчас хорошо понятно, что так долго продолжаться не могло, и на передний план должно было выйти функциональное представление обеспечивающих систем – «как работает» (а не «из чего собрать») обсуждается именно по принципиальным схемам, функциональным диаграммам. Но это произошло не сразу, поначалу появилось множество гибридных диаграмм. Одной из самых известных таких гибридных диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)[151]:

 

 

В этой диаграмме 1996 года уже видно, что кроме безымянных «итераций», по-старинке разбитых на «стадии» во времени, появилась новая сущность, практика (practice, деятельность), именованная по её теоретической инженерной или менеджерской дисциплине (discipline). «Практика» и есть появление функционального аспекта в определениях жизненного цикла.

Работы разных практик (в RUP это практики организационное моделирование, инженерия требований, анализ и проектирование, разработка, испытания, разворачивание, управление конфигурацией, управление проектом, работа с окружением) как-то распределены по стадиям.

На самом графике показано, что интенсивность этих работ по разным дисциплинам разная в разные моменты времени жизненного цикла (часто по-прежнему говорят и «в разные моменты жизненного цикла»). Тем самым на графике интенсивности работ появляются «горбы», отсюда и название «горбатая диаграмма».

С этого момента жизненный цикл перестал обсуждаться как чистые «колбаски» из видов работ и стал представлять собой архитектурное описание деятельности: основные (не все!) практики (функциональные объекты, определявшие, что нужно делать, чем заниматься) в нём как-то назначались на основные работы, разворачиваемые во времени (модульные объекты, указывающие на единицы использования ресурсов и места во времени, когда эти ресурсы задействованы).

 

Жизненный цикл 2.0

 

Недостаточность и ограниченность описания жизненного цикла (описания обеспечивающей системы как деятельности) через метод описания (viewpoint) стадий жизненного цикла была всё очевидней: во всё большем и большем числе проектов (начиная с айтишных проектов) становилось очевидно, что никакого предварительного планирования работ достичь нельзя, разработка велась, как судебные дела, «непрерывно открывающимися обстоятельствами».

Наборы различных архитектурных решений по поводу отнесения практик к работам жизненного цикла получили название виды жизненного цикла (life cycle model[152], модели жизненного цикла).

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

Первый вид жизненного цикла (квинтэссенция подхода 1.0) получил название «водопад» (cascade, каскад).

Как и в водопаде, работы какой-то практики выполняются, созданные рабочие продукты передаются как ресурсы для следующих работ, и больше к этим практикам никакого возврата нет, выполняются работы последующих практик.

Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступеньки настоящего водопада[153]:

 

 

Между стадиями осуществлялась тщательная проверка и приёмка (verification and validation, V&V) рабочих продуктов-результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ. Эти проверки и приёмки с принятием решений между стадиями жизненного цикла получили название гейтов (gates, ворота):

 

 

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

Во всех остальных случаях (и особенно ярко это проявлялось в айтишных проектах) после выполнения работ по любой из практик «водопадного жизненного цикла» (например, инженерии требований в ходе стадии работ «формирование требований») после всех гейтов с их проверкой независимыми экспертами, после всех ожиданий, когда все рабочие продукты соберут по их состоянию готовности на конец стадии (скажем, если речь идёт о требованиях – то это будут абсолютно все требования, и если не готово даже какое-то второстепенное требование, то его будут ждать), всё равно при попытке работы с этими результатами предыдущих стадий находятся ошибки и недоработки и приходится выполнять работы, задействующие практики работ предыдущих стадий жизненного цикла. «Водопад» был только на бумаге в учебниках и в мечтах менеджеров. А в жизни инженерам приходилось признавать, что практики – отдельно, с ними приходилось работать в ходе всего жизненного цикла, а работы назначать (и выделять ресурсы для проведения этих работ) на эти практики приходилось независимо от «водопадной» модели жизненного цикла.

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

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

Поэтому была предпринята радикальная попытка заменить модель жизненного цикла с приматом метода описания работ-стадий на прямо противоположную, функциональную, с приматом метода описания практик. Работы в этой модели учитывались как развёртка применения тех или иных практик работы во времени, а сама линия времени как символ выделения ресурсов для показанных практик была нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в 1978 году, успешно реализован им 1981 и опубликован 1988 году. Этот жизненный цикл получил название спирального [154]:

 

 

На рисунке показан вариант спирального вида жизненного цикла 1989 года, когда уже невозможно было игнорировать тот факт, что в системный подход пришло понятие стейкхолдеров – просто к практикам работы с продуктом (целевой системой) и практиками жизненного цикла (часто называемым в их путанице с работами-модулями «процессом») добавились практики работы со стейкхолдерами.

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

Это был очень несовершенный вариант вида жизненного цикла (по факту он подразумевал много-много идущих подряд «водопадов», список выбранных практик был отнюдь не полный для жизненного цикла от замысла до уничтожения уже использованного воплощения системы, а ограничивался разработкой – но это не помешало спиральной модели считаться основой неутопических вариантов жизненного цикла. Уже разбиравшаяся «горбатая диаграмма» 1996 года как раз представляет собой гибридный вариант спиральной модели (выделены отдельно практики, введены «итерации» как повторения практик) и водопадной модели (введена линейная ось времени, последовательные стадии жизненного цикла, хотя и признаётся, что на каждой стадии жизненного цикла будут работы всех практик, определяемых их дисциплинами).

Современный вариант спиральной модели жизненного цикла носит название «модель пошагового спирального выделения ресурсов» (Incremental Commitment Spiral Model, разрабатывалась Barry Boehm, Jo Ann Lane,‎ Supannika Koolmanojwong, Richard Turner в 2006—2014 годах как продолжение работ по развитию идей спирального вида жизненного цикла) и используется в военных инженерных проектах США[155].

Вот современный вариант, в котором укрупнённые практики обобщённого жизненного цикла раскладываются по линии времени (и обратите внимание, что тут тоже по факту «жизненный цикл проекта», так как не входит замысел, эксплуатация и вывод из эксплуатации):

 

 

Переход от «проектного» понимания жизненного цикла как удовлетворяющего только менеджерски-логистический взгляд на работы обеспечивающей системы с точки зрения «как сделать систему работ-модулей» с производством и потреблением ресурсов проекта в строго запланированное время, акцента на своевременную закупку ресурсов и учёт рабочих продуктов, контроль выдаваемых обещаний и приёмок-сдач (координационные акты DEMO) к настоящему времени завершился.

Сегодня «модель жизненного цикла» (в том числе модель жизненного цикла проекта) упирает не на модульную структуру работ, а на компонентную структуру практик, ответ на вопрос инженера предпринятия (enterprise engineer, инженер, который организует предпринятие, а не создаёт целевую систему) «как будем работать». Модель жизненного цикла документирует архитектурные решения о назначении модулей-работ на компоненты-практики.

Поэтому время там «логическое» (функциональное), а не «физическое» (конструктивное, для выстраивания последовательности работ).