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

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

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

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

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

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

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

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

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

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

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