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

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

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

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

Первый вид жизненного цикла (квинтэссенция подхода 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, инженер, который организует предпринятие, а не создаёт целевую систему) «как будем работать». Модель жизненного цикла документирует архитектурные решения о назначении модулей-работ на компоненты-практики.

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