А если посмотреть на постепенный переход на платформенный способ организации продуктных линий (product lines, иногда product families, когда из стандартных модулей собираются разные конфигурации системы для разных потребностей, и это происходит на нескольких платформенных уровнях), жизненные циклы разных платформ как частей системы могут быть переплетены причудливым образом. Нужно всегда помнить, что системы определяются субъективно, в зависимости от деятельностного/стейкхолдерского интереса, и тем самым определение жизненного цикла системы тоже субъективно.
Различные классификации жизненных циклов (в том числе по видам жизненных циклов) тоже не жёсткие, учитывая вероятностную логику отнесения к классам. Более того, вид жизненного цикла может потихоньку меняться по мере его прохождения: заменяться отдельные инженерные практики, практики менеджмента, в том числе даже практики управления работами. Поэтому нужно всегда помнить, кто (какой стейкхолдер) говорит о жизненном цикле, для чего был затеян разговор, какие практики управления жизненным циклом и управления работами доступны для использования в проекте, какое место жизненного цикла проекта в жизненном цикле системы, какие вероятности того, что жизненный цикл системы будет проходить не так, как ожидается командой проекта.
Обязательно определите жизненный цикл не только вашей системы, но и использующей системы. У обеспечивающей системы тоже есть свой жизненный цикл, её ведь тоже создают – часто те же люди, которые составляют её часть в ходе работы над целевой системой, но играющие при этом другие стейкхолдерские роли.
Вот это одновременное удержание внимания на жизненном цикле всей системы в первую очередь (окружение) и жизненном цикле проекта (целевое) во вторую очередь и отличает системного мыслителя. Системное мышление – это всегда первый мыслительный ход от целевого объекта рассмотрения наружу, а не внутрь. И только после разбирательства с окружением можно рассмотреть структуру целевого объекта.
8. Системная схема проекта и основной жизненный цикл
Системная схема проекта
Стандарт OMG Essence198 предложил набор семи основных (essence, существенный, основной) альф проекта программной инженерии. Мы немного доработали этот набор альф для более общего случая системной инженерии199, где информационные системы только один из многочисленных видов разрабатываемых систем. Эти альфы объединены в системную схему проекта (Рис. 8).
Оригинальный набор альф был получен путём экспериментального ответа на вопрос: какие объекты внимания команды присутствуют в каждом проекте разработки? Было рассмотрено более 250 проектов, и в системную схему попали только те из них, которые встречались буквально в каждом проекте.
Основных альф проекта оказалось семь: возможности, стейкхолдеры, определение системы, воплощение системы, работы, технология и команда.
Эти альфы все тесно связаны отношениями, на диаграмме показаны отнюдь не все отношения – это просто напоминание о том, что связей много, и причины и следствия в проекте могут быть существенно разнесены во времени и пространстве. Да и самих альф в проекте много больше: это только альфы самого высокого уровня, основные, а у них есть многочисленные подальфы, о которых подробней будет рассказано позже.
Три области интересов (area of concerns) группируют эти семь альф по трём темам (помним, что «интерес» это интересующая разных стейкхолдеров тема, а не «чего хочется». «Чего хочется» это будет не сам интерес, а оценка/assesment интереса разными стейкхолдерами):
• Клиентская (customer) область интересов относится к использующей системе. В ней альфа возможности выполнить проект, эту возможность дают (внешние) стейкхолдеры, и тем самым клиентская область интересов разворачивается вокруг использующей системы, речь идёт о потребностях стейкхолдеров. В команде проекта этим занимаются технопредприниматели, специалисты по маркетингу и продажам. Ведущие практики тут – технологический менеджмент и предпринимательство.
• Область интересов инженерного решения (solution) относится к определению и воплощению целевой системы. Это то, чем в команде проекта будут заниматься самые разные инженеры, создающие сначала определение системы (чтобы уменьшить число проб и ошибок), а затем работающие над удовлетворяющим этому определению системы воплощением системы. Стейкхолдеры используют воплощение целевой системы в использующей системе, удовлетворяя тем самым свои потребности. Ведущие практики – инженерные.