Системное описание
Системная документация/документация системы (system description) --- это документы/артефакты/рабочие продукты, реализующие альфу описаниясистемы (system definition). Если система есть, то она обычноописана: подразумевается, что существует концепция использования системы, существует её проект/design(который включает концепцию системы, архитектуру как набор архитектурных решений, а ещё инженерные обоснования, детали изготовления, описание метода/технологии изготовления и т.д.). Мы это можем просто ещё не знать, хотя оно и есть --- система-то в пространстве-времени, и время тут может быть в некотором будущем, а мы в настоящем, и поэтому просто ещё не подумали об этих описаниях и не документировали их. Или мы просто не нашли ещё исполнителей, делающих такие описания проектных ролей, и не догадались ещё задать им правильный вопрос --- и они нам дадут недостающие части описания, они-то их знают, это только мы пока не знаем. В любом случае: есть система --- есть концепция использования, есть концепция системы, есть её архитектура, возможно просто пока не выявленные/discovered (либо не найдены уже имеющиеся, либо их ещё не придумали и не документировали): типы мета-мета-модели мы уже знаем, осталось только получить сами объекты. Это не так, что «мы не знаем, есть они или нет». Они есть, вот же их типы --- значит, должны быть, внимание к ним уже есть, оно наводится уже известными вам типами! Надо только их выявить или даже спроектировать. Когда вы идёте в совсем новый проект, вы уже много знаете о том, за чем вам там надо следить, у вас не полная неизвестность! Вы уже знаете мета-мета-модель, а иногда и мета-модель (если будете заниматься чем-то в прикладной предметной области, практику которой вам уже довелось освоить). Поэтому что-то о мире вы уже знаете, но что-то (модель, безо всяких «мета») придётся узнать в самом проекте, да ещё и отслеживать смену состояний.
Чтобы явить миру описание системы, его нужно записать на каком-то носителе, чтобы появилась системная документация --- записать все эти модели (а иногда и тексты, фотографии, которые не очень похожи на модели, тем не менее они тоже отражают только что-то важное в реальной системе, описывают что-то в ней, так что смело считаем их тоже моделями, разве что это менее формальные описания) на бумаге, или представить в электронном виде как записи в базе данных. Есть система --- значит кто-то её выделил из окружающего мира, думает о ней. Думает --- значит что-то в ней описывает, или описывает её в целом, «система в глазах смотрящего». Если не может описать, значит систему из окружающего мира ещё не выделил. Мы должны чётко различать существующеевсегда описание системы как альфу и существующуюне всегда документацию системы как рабочий продукт/артефакт/документ.
Иногда переводят описание системы/system definition как «определение системы». В этом случае нельзя путать термин со «словарным определением», типа «наша система --- это то-то и то-то». Нет, это самая разная информация о воплощении системы, она включает самые разные модели целевой системы, а часто это конструктивное описание (в смысле конструктивизма: «чтобы описать объект, надо задать операции его построения»), так что описывается система создания и её операции --- это и будет описание системы. Так что одной фразой «определения из словаря» её не заменишь, тут совсем другое значение термина system definition.
Стандарт ISO 42010 даёт рекомендации о том, как думать о системном описании/описании системы. Сам стандарт говорит только об архитектурном описании, причём в старом понимании архитектуры, но его положения вполне применимы к любым описаниям, то есть и концепции использования, и концепции системы, и архитектуре.
Вот задающая мышление об описаниях системы диаграмма из этого стандарта, модифицированная с использованием положений OMG Essence:
В жизни при прямой инженерии обычно всё начинается с разработки (выявления, придумывания, согласования между собой) и документирования каких-то ролевых видов описания (частей концепции использования, концепции системы, архитектурных решений и так далее), а потом от описаний команда проекта переходит к воплощению системы в физическом мире (изготавливает/производит систему, вводит её в эксплуатацию) --- и всё это в непрерывном цикле развития системы. Если это обратная инженерия/reverse engineering, то всё наоборот: берём систему в физическом мире и восстанавливаем все описания для уже готовой системы. Обычно в проектах для надсистемы идёт обратная инженерия, а для целевой системы --- прямая.
Если вы попали в какую-то организацию (клиента, контрактора, или только пришли в команду проекта), то вы делаете обратную инженерию этой организации: понимаете, что происходит с системами создания. Если вам надо организовать создателя системы --- делаете прямую инженерию, готовите все эти описания и доводите их до людей (курс «Системный менеджмент» как раз об этом).
В философской логике рекомендуют всегда начинать с воплощения системы, даже если это воплощение будет существовать только в будущем: нужно представить и описать возможный мир, в котором воплощение системы существует! Ни на секунду не нужно забывать, что нужно-то воплощение системы, а описание (данное нам в виде информационных моделей, чертежей, инструкций по изготовлению и т.д.) нужно только в силу того, что без описания очень трудно воплотить в жизни работающую систему.
Заданного направления чтения (слева направо, или справа налево, или снизу вверх, или сверху вниз) этой диаграммы объектов внимания для системного описания нет. Разные проектные роли для разных своих целей читают эту диаграмму в разных направлениях. Но главный элемент диаграммы --- это, конечно, воплощение системы. Ради него вся деятельность и затевается, его всегда нужно держать во внимании (напоминаем, что все подобные диаграммы --- это чеклисты для объектов, которые нужно удерживать во внимании при мышлении о системах).
Диаграмма начинается с уже знакомого нам различения воплощения (realization) и описания (definition) системы.
Для простоты диаграммы большинство отношений (кроме одного: удовлетворяет/описывается в одну сторону и характеризует/описывает в другую сторону) приведены только с одним наименованием связи, но это не значит, что не существует обратного отношения. Это общее свойство всех подобных схем: даже отношение «часть-целое» в одном направлении читается «включает_в_себя» или «состоит из», в другом направлении читается «является_частью» или «входит в состав».
Каждая связь между объектами этой диаграммы может быть прочтена в двух направлениях, например «описание системы выражается документацией системы/системной документацией», «системная документация документирует системное описание». Говорят и «системная документация», и «документация системы», и «системное описание», и «описание системы».
Обратите внимание, что документация не фиксирует, а документируетпостоянно меняющиеся в ходе проекта описания! Избегайте слова«фиксирует», потому как люди обычно думают, что это означает не документирование (как думаете вы, произнося слово «фиксирует»), а объявление описания уже не изменяющимся.
Фиксация или фиксирование требований (много реже так говорят о фиксации концепции использования, и это была одна из причин отказа от разработки требований в пользу концепции использования) для большинства людей означает не запись требований на бумагу или в базу данных, а объявление текущего состава требований стабильным и неизменяемым! Но в системном мышлении вы лучше и лучше описываете систему (или описываете всё более лучшую систему, по мере понимания того, как именно она будет использоваться, в каком окружении), меняя и меняя тем самым концепцию использования --- документирование этому не мешает, модели системы не «фиксированы» ни в один момент времени проекта! Вы можете какую-то версию административно объявить стабильной. Инженеры говорят в этом случае о базисе/baseline, но это не означает «фиксации»! Просто изменения системных описаний будут собираться и документироваться в других артефактах (документе «рабочей версии», а не документе уже утверждённого «базиса»), а потом базис будет меняться по какой-нибудь административной процедуре управления изменениями проекта/change management. Но и тут изменения: trunk development
Вот эта же схема на английском языке:
Описание системы (system definition) состоит из ролевых/аспектных/частных описаний системы (views), которые определяются целевыми характеристиками (concerns, ролевыми предметами интереса/озабоченностями) и задаются аспектными методами описаний (viewpoints). Ролевые/аспектные/частные описания системы --- это как раз концепция использования (разрабатывается ролью инженера-проектировщика), архитектура (формулируется ролью инженера-архитектора), и так далее --- описания, которые делаются различными инженерными ролями, даются в курсе «Системная инженерия». Но в менеджменте это будет, например, не просто архитектура, а орг-архитектура, а в качестве «концепции использования» у организации будет выступать бизнес-модель, где обосновывается необходимость организации (и за неё будет ответственной роль бизнесмена). Аспектные описания --- это что угодно, что описывает систему удобным способом для обсуждения ролевых интересов.
На всякий случай уточним, что тут слово «частный» используется в значении «не полное, не всё --- один из видов описания для всей системы», а не в значении «посвящённый части системы, взятой по отношениям часть-целое». «Частный» это не про «часть системы»!
Конечно, ролевых/аспектных/частных описаний может быть множество. Например, роль могут интересовать финансы. Тогда ролевое описание --- финансовое, модели там будут --- бухгалтерский баланс, отчёт о прибылях и убытках, поток денежных средств. Как сделать эти описания? Эти описания могут быть сделаны по методу описания РСБУ (Российская система бухгалтерского учёта) или МСФО (Международная система финансовой отчётности), а мета-модели --- это форматы представления бухгалтерского баланса, отчёта о прибылях и убытках, потока денежных средств в соответствующих ролевым методам описания (РСБУ или МСФО). Если финансиста заинтересуют оба метода описания, то он получит два описания --- и по РСБУ, и по МСФО. Как будут документированы эти описания? Или на бумаге, или в табличках Excel, или в базе данных компьютерной бухгалтерской программы --- в любом случае, содержание описаний можно обсуждать без обсуждения формата представления на носителях информации.