Системное описание или описание системы всегда существует, если в физическом мире выделена система. Раз уж своим вниманием выделили систему, то значит у вас есть какие-то особые пожелания к ней, то есть вы не произвольно её выделяете[1] из окружения. Хотя, возможно, до конца не осознаете все пожелания или не можете сразу дать полного описания системы. Тем более, что полное описание системы зависит от всех заинтересованных лиц (проектных ролей).
Системная документация или документация системы – это документы[2], которые описывают систему. Описание есть всегда[3], если есть система, но документация системы существует не всегда, ее необходимо создавать[4] или записать на каком-то физическом носителе.
Системное описание состоит из требований, архитектуры и неархитектурной части[5]. Требования описывают систему как «черный ящик» или снаружи, а архитектура и неархитектурная часть – как «прозрачный ящик» или внутреннее устройство системы. Системная документация состоит из списка требований, архитектурной документации и рабочей документации. Обсудим данные понятия подробнее.
Требования и потребности
Требованиями описывается то, что делает система. Упоминание «черного ящика» означает, что требованиями описывается внешнее поведение системы, выполнение её функции в надсистеме. В требованиях ничего не говорится о внутреннем устройстве системы, она представляется как «черный ящик». Например, требование к системе «легковой автомобиль»: максимальная скорость не менее 250 км/ч, вес не более 2 тонн, разгон до 100 км/ч за 3 сек и т.п.
Требования возникают у проектных ролей, как внешних, так и внутренних. Учитываются требования только тех ролей, интересы которых принято учитывать при создании целевой системы. Поэтому решение о том, какие роли учитывать непосредственно влияет на требования, а потом на архитектуру, и впоследствии на воплощение системы. Инженер по требованиям в результате коммуникации с заинтересованными лицами самостоятельно определяет список требований, с которыми далее работает архитектор системы.
Как мы говорили выше, описание системы есть всегда, когда есть система. Соответственно требования существуют тоже всегда, если определена система или есть внешние проектные люди, которые что-то хотят от системы. Выделяя вниманием систему, это делается исходя из каких-то требований, которые можно и не осознавать. Выделив систему «легковой автомобиль», мы разу определили главное требование – способность самостоятельно передвигаться и перевозить пассажиров. Далее работа с требованиями помогает лучше описать будущую систему. В зависимости от учитываемых проектных ролей легковой автомобиль может получиться разным. При работе с требованиями их необходимо документировать, и управлять требованиями[6].
Когда речь идет о требованиях, то обязательно подразумевают, что в ответ на эти требования будет предложена функция конкретной системы. Обычно, если не уточняется система, то значит речь идет о требованиях к целевой системе. Или говорят ещё системные требования (system requirements). Если же речь идет о требованиях к надсистеме, то они называются потребностями или нужды внешних проектных ролей (stakeholder needs)[7]. Требования и потребности в одном проекте нельзя путать, они описывают разные системы: требования к целевой системе, а потребности – это требования к надсистеме. Например, для надсистемы «поездка» и целевой системы легковой автомобиль: потребностями будет комфортное круглогодичное передвижение из пригорода в город, а требование – проходимость, настраиваемый климат в салоне, не укачиваемость, а также могут быть требования к скорости, весу и времени разгона.
Требования к целевой системе вытекают из потребностей. В задачу инженера по требованию входит связка выявленных потребностей и требований, а в задачу архитектора – связка требований с архитектурой системы.
Архитектура системы
Системная архитектура (system architecture), как и требования – часть системного описания. Однако, в отличие от требований, архитектура описывает важнейшие инженерные решения о том, как устроена целевая система. Требования описывают систему как «черный ящик», а архитектура – как «прозрачный ящик». Все основные части целевой системы называются архитектурой системы.
Также как и про требования, про архитектуру всегда можно говорить, начиная с момента выделения вниманием системы из внешнего мира. Но не всегда существует архитектурная документация. Созданием данного рабочего продукта занимается архитектор, который использует соответствующие архитектурные практики. Например, теория решения изобретательских задач призвана находить архитектурные решения и создавать архитектурную документацию новой технической системы, а для системы предприятия[8] используются практики разработки архитектуры предприятия.
Самое важное внутреннее (или архитектурное) строение системы можно описать с разных точек зрения. В книге «Системное мышление 2020»[9] приводится пример с ножницами, в котором показано несовпадение функционального и модульного рассмотрения системы как «прозрачного ящика».
В ножницах выделяют функциональные части – это ножевой блок и ручка. Данные части – это функциональная архитектура системы ножницы. Функциональная архитектура, в первую очередь, интересует инженеров, но не интересует менеджеров. Интерес инженеров – как работает система. Модульная архитектура ножниц состоит из одной половинки и другой половинки. Модульное устройство системы менеджеров интересует в обязательном порядке, поскольку им необходимо понимать этапы изготовления системы. Кроме функционального и модульного рассмотрения существует компоновка или места/размещения модулей[10].
Неархитектурной функциональной частью ножниц может быть упор для безымянного пальца в парикмахерских ножницах, а модульная неархитектурная часть – болтик для крепления двух половинок[11].
Понятие архитектуры важно для создания системы. Без понимания архитектуры невозможно создание успешной системы или эта система будет создаваться длительное время и с большими финансовыми затратами. Архитектор системы принимает важнейшие решения о том, как должна быть устроена система, чтобы удовлетворить требованиям. Например, чтобы удовлетворить вышеуказанным требованиям в скорости, весе и времени разгона легкового автомобиля архитектор может принять решение о том, чтобы использовать электрический двигатель. Это существенное архитектурное решение, которое определяет остальное устройство автомобиля.
Архитектурная документация в простейшем виде представляется списком принятых важных инженерных решений[12]. Неархитектурная документация или рабочая документация представляется точными инженерными описаниями (расчётами, формальными моделями, в том числе компьютерными). Исходя из данных документаций заказываются необходимые модули и происходит сборка или изготовление системы. Используя аналогию со стадиями жизнедеятельности деятеля, для того, что чтобы начать изготовление системы (стадия «Реализация») необходимо:
- пройти стадии «Потребление информации» и «Размышления», чтобы определить группы потребителей и их проблемы;
- пройти стадию «Стратегирование», чтобы определить те проектные роли, которые будут учитываться, выявить потребности и требования, составить архитектурное и неархитектурное описание;
- пройти стадию «Планирование», чтобы определить этапы проекта и нарезать внутренним ролям работы по практикам.
Понятие архитектура системы будет использовано в главе 12, когда будем переходить от требований к внутреннему устройству системы «Деятель», а именно к функциональной архитектуре. С самой функциональной архитектурой деятеля вы уже знакомы по модели «Человек-платформа». В этой модели представлены три функциональные части – мастерство собранности, мыслительное мастерство и прикладное мастерство.
Таким образом, начав с выделения заинтересованных проектных ролей, их потребностей и требований, трансдисциплина системное мышление определяет необходимость составления архитектурной документации неархитектурной документации, а в дальнейшем определение работ по созданию успешной системы.
Понятия: системное описание; требование, потребность; архитектура или системная архитектура, неархитектурная часть; архитектурная документация
- [1] Если выделяете произвольно, то, скорее всего, у вас нет проекта и реальной деятельности, а вы просто играетесь или философствуете на тему.
- [2] Или артефакты, рабочие продукты.
- [3] Обычно на старых предприятиях имеется дядя Петя или тетя Валя, которые держат в голове все описания системы, но нет полной документации. Несмотря на отсутствие документации, системы создаются и работа выполняется.
- [4] Документация или рабочие продукты системного описания составляются с помощью определенных практик. Например, с помощью практики бухгалтерского учёта составляется рабочий продукт – бухгалтерский баланс, который является одним из описаний системы «предприятие».
- [5] Обычно архитектура и неархитектурная часть вместе называется проектом системы. В данном случае термин «проект» означает не деятельность, а описание (design).
- [6] Управление требованиями – важная часть инженерии требований. Требования формируются в течение определенного времени, иногда достаточно длительного, за который они могут дополняться и существенно изменяться.
- [7] Для внешних проектных ролей надсистема (по отношению к нашему проекту и целевой системы) может быть целевой системой, поэтому потребности для нашей команды будут требованиями для внешних проектных ролей. Для команды, ответственной за подсистему, требования к целевой системе будут потребностями. Термины потребности и требования определяются относительно двух смежных системных уровней.
- [8] Предприятие – тоже система, и соответственно существует архитектура предприятия.
- [9] Однако, описание системы как «прозрачного ящика» не ограничивается только тремя приведенными в учебнике – функциональное, модульное и места/размещения.
- [10] Об этом подробнее изучайте в курсе «Системное мышление».
- [11] Картинка из учебника «Системное мышление 2020». Здесь важно отметить, что неархитектурная часть хоть и не относится к главным частям системы, но без них система не сможет выполнять эмерджентное свойство (функцию).
- [12] Архитектурная документация может быть в форме текста, диаграмм, моделей на архитектурных языках, но важно, чтобы данные решения не оставались в голове отдельных людей, иначе трудно добиться коллективной работы.
Источник: учебник/онлайн-курс «Введение в системное мышление»