Диаграмма системной схемы проекта

Стандарт OMG Essence^[1] предложил в качестве метода описания/viewpoint метода создания и развития систем язык/language такого описания и в качестве примера для начала описания набор семи основных/kernel (essence, существенный, основной, в самом стандарте они названы kernel, но сам стандарт называется essence) альф проекта программной инженерии, а потом объявил этот стандарт более общим, приложимым к системной инженерии в целом. Эти альфы стандарт разложил в так называемые основные/kernel области интереса, в которых размещались тесно связанные основные альфы. Все остальные альфы предлагалось считать подальфами этих основных.

Этот набор семи основных альф был получен путём экспериментального ответа на вопрос: какие объекты внимания команды присутствуют в каждом проекте разработки? Было рассмотрено более 250 программистских проектов, и в основные альфы попали только те, которые встречались буквально в каждом проекте.

Например, не во всех проектах встречалась архитектура системы, но во всех проектах встречались требования --- в основные альфы изо всех описаний системы попали только требования, но не попала архитектура. А исходный код и вовсе отнесли не к описаниям системы (такой альфы и не было), а посчитали чуть ли не самой системой (легко спутать работающую программу и её исходный код!).

Стандарт пришлось адаптировать в части этого набора основных альф: в нём предусмотрен язык/language, который вводит понятия, использующиеся для описания метода создания и развития систем: альфы и подальфы, области интереса, рабочие продукты и т.д., не говоря, какие они. Это точно так же, как в любом другом стандарте описания метода разработки (SPEM, ISO 24744), которые были в первом их поколении ориентированы на методологов, они тоже вводили какой-то свой язык/language. Но OMG Essense был стандартом второго поколения, он заявил, что ориентирован на людей-разработчиков как его пользователей, а не «далёких от народа» методологов, поэтому и предложил кроме языка/language ещё и пример моделирования метода разработки --- объекты тех типов, которые предложены в языке, то есть конкретный набор основных альф и областей интереса (возможность проекта, внешние проектные роли, требования, программная система, команда, работы, способ работы), ожидая, что в каждом проекте будут потом просто приводить к ним подальфы, или даже заменят этот набор, если он совсем не будет подходить. И описал эти альфы, увязав в системную схему проекта --- этот пример моделирования метода разработки более-менее универсальным набором основным альф выгодно отличал стандарт второго поколения от стандартов первого поколения, которые выходили без такого примера в тексте стандарта. С новым стандартом было проще работать: он «из коробки» уже что-то говорил про метод разработки, за какими альфами надо следить в проекте, какие состояния каких альф ожидать.

Мы немного доработали^[2] этот набор основных/kernel альф и областей интереса, сохранив язык/language стандарта. Это вполне предусмотрено стандартом: в нём говорится, что можно оставить язык/language, но заменить основные понятия, предлагаемые на этом языке (kernel: конкретный набор альф из нескольких конкретных областей интереса, к которым предлагалось потом привязывать все остальные альфы как подальфы) на какие-то другие, более подходящие. Эта доработка оказалась удачной. Так, требований в жизни больше нет, а в стандарте они до сих пор есть в основных альфах, вот мы их и убрали из основного/kernel набора. Зато добавили описание системы (предполагая, что подальфами там будут концепция использования, концепция системы, «рабочка» и всевозможные другие описания). Вы тоже должны дорабатывать набор основных/kernel альф для вашего проекта (материал нашего курса тут только ориентир!), но использовать язык/language этого стандарта, то есть типы «альфа», «область интереса», «рабочий продукт».

Эти основные альфы в стандарте было предложено считать связанными, это отражалось в системной схеме проекта, и мы приведём её не для основных альф из стандарта, а для доработанного нами основного набора альф:

Тут видны три области интереса:

Область интереса надсистемы (в OMG Essence это примерно соответствует customer area of concern). Это состояния::предметы интереса для внешних проектных ролей::альфа, которые дают организации::альфа коммерческую возможность::альфа выполнить проект. Надсистема и потребности --- это подальфы альфы возможности, а ещё для возможности выполнения проекта важна ожидаемая от него прибыль (превышение дохода от проекта над затратами на него). Использование --- это про удовлетворение потребностей в момент эксплуатации, деньги внешние проектные роли проекту платят за удовлетворение потребностей, за улучшение работы надсистемы от работы в ней целевой системы, а не за просто работоспособность целевой системы в момент выпуска (испытания), им нужно использование! Если утюг работает, но почему-то не гладит, то денег не будет! Если игровой софт работает, но игра удовольствия не приносит, то денег не будет! Если не отслеживать в ходе всего проекта альфы зоны/области интересов надсистемы, то результаты проекта могут оказаться никому не нужными --- возможность выполнения проекта может исчезнуть в любой момент времени проекта, внешние проектные роли в любой момент могут перестать поддерживать организацию проекта материально, «продукт у нас есть, но его никто не покупает».
Область интереса целевой системы (в OMG Essence это solution area of concern) относится к альфам описания, воплощения и эксплуатации/использования (на диаграмме она названа «работа (operations/service)», не привязывайтесь к именам-терминам!) целевой системы. Это то, чем в организации проекта будут заниматься самые разные инженеры целевой системы. Ведущие практики работы по изменению состояния альф области интереса целевой системы ходе проекта --- прикладные инженерные, занимаются этими альфами главным образом инженеры той предметной области, к которой относится целевая система.
Область интересов создателя относится к выполняющей проект организации (оргзвена, выполняющего проект: команда, коллектив из нескольких команд, предприятие, «производственная кооперация» из нескольких предприятий, рабочая группа проекта и т.д.), работам и описаниям организации проекта. На диаграмме под словом «проект» в альфе «описание проекта» названа организация проекта (помним, что слово «проект» многозначно! С равным успехом оно может означать и работы организации, значение зависит от контекста). Организация, напомним, это группа людей и оборудования, в которой понятно как устроено распоряжение трудом и ресурсами.

Основных альф получается вроде как три для каждой системы (чётко видны две практически одинаково устроенных области интереса целевой системы и системы создания целевой системы):

Воплощение системы, которое проходит состояния его создания и развития (в том числе созданная система используется, производя работы)
Описание системы (проект/design --- все необходимые для создания системы модели), которое постепенно появляется в ходе создания и развития системы
Работы готовой системы в ходе её использования, метод работы задаётся описанием системы, планы работы или вычисляются по ходу дела, или тоже задаются в описании, но главное --- это переход от времени создания к времени эксплуатации, помним, что воплощение системы в конечном итоге работает, а не только создаётся!

С другой стороны основных альф на диаграмме не три, а больше, ибо добавляются:

Повторение мотива из «трёх основных альф» по цепочке создания: организация проекта::создатель (то, что это создатель, отдельно указано в области интересов и выделено голубым цветом) создаёт описание целевой системы, воплощает систему и ещё часто создатель будет оператором созданной системы (появился даже слоган «ты это построил, ты и будешь это эксплуатировать, будешь оператором», you build it, you run it!). Это повторение «мотива из трёх альф» легко продолжить. Например, легко можно представить, что если целевой системой будет станок, то работы станка будут что-то там создавать в какой-то целевой системе клиента. Показано всего два повторения набора основных альф: для целевой системы (жёлтый фон области интереса целевой системы) и для системы создания целевой системы (голубой фон). Связаны альфы по большому счёту все со всеми, показаны для удобства рисования только некоторые связи. В приведённом примере (повторим, это только пример основных альф! Дальше мы покажем больше примеров!) целевая система вроде как не очень продвинута по шкале разумности, поэтому она просто удовлетворяет описанию. А создатель (организация проекта) более разумный, поэтому не просто «удовлетворяет описанию», но подчёркнуто, что описание создателя задаёт роли, а ещё подчёркнуто, что описание (организации) проекта задаёт методы работы для этих ролей. Но в целом, конечно, структура области интересов систем из цепочек создания одна и та же: воплощение системы и её описание (основное внимание к времени создания) и работы (чтобы не забывать, что в конечном итоге волнует момент использования/эксплуатации/работы/функционирования).
Кроме того, у всех систем есть надсистемы. К области интересов надсистемы приписывается и надсистема целевой системы, и внешние проектные роли из цепочки создания надсистемы. Область интереса надсистем выделена салатным цветом. В минимальной диаграмме она показана одна для целевой системы (относится к окружению целевой системы, для которого существуют потребности внешних проектных ролей, дающие коммерческую возможность проекта), поэтому и единственное число --- «надсистема». Дальше могут быть несколько разных областей интереса к разным надсистемам для разных систем.

Эти альфы все тесно связаны отношениями, на диаграмме показаны отнюдь не все отношения --- это просто напоминание о том, что связей много, и причины и следствия в проекте (как и в любой системе) могут быть существенно разнесены во времени и пространстве. Да и самих альф в проекте много больше: это только альфы самого высокого уровня, основные/essence, а у них есть многочисленные подальфы, о которых подробней будет рассказано позже. И это только два звена цепочки создания из большого графа создания, который надо моделировать в проекте.

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

Если это всего-навсего чеклист, то диаграммная форма не нужна. Вот пример записи в виде списка (первый уровень --- это область интереса, второй уровень --- альфы):

Надсистема
1. Возможность проекта
2. Внешние проектные роли
Целевая система
1. Воплощение целевой системы
2. Работы целевой системы
3. Описание целевой системы
Создатель
1. Организация проекта
2. Работы создания
3. Описание организации проекта

Этот список в использовании для мониторинга состояния проекта имеет много преимуществ перед диаграммой:

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

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

Область интересов Альфы Подальфы первого уровня 1. Надсистема 1.1. Возможность проекта 1.1.1. Бюджет 1.1.2. Конкурентное преимущество 1.2. Внешние проектные роли 1.2.1. Пользователь 1.2.2. Контрактор 2. Целевая система 2.1. Воплощение целевой системы
2.2. Работы целевой системы
2.3. Описание целевой системы
3. Создатель 3.1. Организация проекта
3.2. Работы создания
3.3. Описание организации проекта

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

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

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

http://www.omg.org/spec/Essence/ ↩︎
Towards a Systems Engineering Essence, http://arxiv.org/abs/1502.00121, опубликовано в краткой форме также в Software Engineering in the Systems Context, https://www.amazon.com/Software-Engineering-Systems-Context-Jacobson/dp/1848901763 ↩︎

Назад Вперед

Диаграмма системной схемы проекта ​

Диаграмма системной схемы проекта