OSS / Системноинженерное мышление в управлении жизненным циклом(2014)

TechInvestLab, 14 июня 2014

141

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

Заметим, что некоторые элементы получили полные обозначения сразу в двух аспектах. Для однозначного указания на объект достаточно иметь только одно полное имя, а остальные имена пусть указывают на "надсистему".

TechInvestLab, 14 июня 2014

142

Каждое обозначение -- это имя холона (объекта, который состоит из частей, но сам является частью другого объекта), ибо система по определению -- это холон в системной холархии (у любой системы есть её элементы-подсистемы и она является элементом в надсистеме). Поэтому все имена компонент, модулей, мест подразумевают, что перед ним будет имя надсистемы, а после него -- подсистемы. Например, ...=контроллер=процессор=кэш первого уровня...

5. Определение системы: требования, архитектура, неархитектурная часть проекта

Определения и описания

Определения и описания

Перед тем как систему воплотить, её нужно как-то определить (define). Это определение системы -- основная альфа инженерного проекта, а выражается она рабочими продуктами, которые совместно называются описанием (description) системы. Конечно, есть огромное число вариаций этой терминологии (например, определение системы называют "проектом", а описание -- "проектной документацией"), тем не менее нужно понимать разницу: определение системы всегда есть, если есть система (если система никак не определена, то откуда вообще мы знаем, о какой системе мы говорим?!) -- но вот описаний может не быть, если никто не потрудился задокументировать определение системы в

TechInvestLab, 14 июня 2014

143

рабочих продуктах.

Определение системы как альфа включает в себя основные подальфы (это только основные подальфы, их может быть много больше):

●Требования (определение системы как "чёрного ящика")

●Архитектуру (важнейшие инженерные решения, определяющие систему как "прозрачный ящик")

●Неархитектурная часть проекта (все инженерные решения, которые будут сочтены не самыми важными) -- "рабочка".

Очень редко архитектурные (важные, требующие существенных переделок при их изменении) решения изобретаются заново, чаще они повторноиспользуемы (т.е. «знания»).

Архитектурные решения – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания.

Развитие и лидерство в инженерии – это обычно добавление знаний, предложение новых архитектур, исходя «из первых принципов».

TechInvestLab, 14 июня 2014

144

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

Часто выделяют проект/design как совокупность архитектурной и неархитектурных частей (вся архитектура -- это design, но не весь design это архитектура). Часто требования не считают относящимися к проекту. Иногда архитектурный проект называют "эскихным проектом", иногда "техническим проектом", иногда просто "проектом", тогда описания неархитектурной части проекта называют "рабочей документацией". А ещё есть "исполнительская документация" -- это описание системы "как построено/изготовлено" (as built) в отличие от "проектной документации" (as designed).

Конечно, определений (и, соответственно, описаний) системы много больше. Так, часто в plant model (описании, или "информационной модели" установки) выделяют проектную-design модель и проектную-project модель (в русском языке это неразличимо, увы). Design часть описания -- это описания функции и конструкции самой целевой системы (инженерного решения -- проект в смысле инженерный проект), а project-часть -- это описания предпринятия (обеспечивающей системы: работы и соответствующие планы, команда и т.д. -- проект в смысле проектного управления).

Обобщение ISO 42010 на определение системы

ISO 42010 "Systems and software engineering -- Architecture description" вполне может быть обобщён с архитектурного на все виды описаний. Основные его положения можно увидеть на этой диаграмме:

TechInvestLab, 14 июня 2014

145

Описания -- это рабочие продукты, которые выражают определение системы. Обратите внимание, что определение системы на диаграмме выражено значком альфы, а описание -- значком рабочего продукта.

Самые важные связи на диаграмме обозначены красным: то, что

●воплощение системы удовлетворяет определению системы, а определение

TechInvestLab, 14 июня 2014

146

системы характеризует (а пока системы нет, то определяет) воплощение системы

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

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

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

Методы описаний поставляются наукой. Дисциплины, задающие виды моделей -- это научные (учебные, профессиональные) дисциплины, предлагающие различные виды моделей. Модель (тут мы чаще всего будем говорить об информационной модели, а не о физической "натурной" модели) -- это система M, которая может быть использована в каких-то пределах для получения знания о системе S. Модель в разы, разы и разы проще реальной системы S, она опускает неполезную для интереса стейкхолдера информацию, и предоставляет полезную.

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

●библиотечный (library) в переносном смысле слова -- описанный в какой-то литературе, и на это описание можно сослаться

●Собственной разработки (что по факту означает необходимость проведения научной работы: изобретения каких-то абстрактных сущностей, постоения какой-то новой теории, разработки новой нотации, а затем документирования результатов этой работы).

Нужно запомнить: существований без метода описания не существует. Если вы пишете прозой, то метод описания -- "проза, жанр эссе". Если вы описываете финансы (а хоть и финансовый баланс), то вы должны указать метод: российская

TechInvestLab, 14 июня 2014

147

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

Очень часто метод описания известен неявно (например, машиностроительное предприятие будет использовать "чертежи по ЕСКД"). Но стоит этим чертежам попасть в иностранную фирму (или строительную организацию, привыкшую к "чертежам по СПДС"), и содержание этих чертежей становится уже не таким понятным. Поэтому явное указание метода описания -- это хороший тон в инженерных проектах. Если вы приводите диаграммы сценариев использования (use case diagrams) для описания требований, то обязательно скажите, что это use case diagrams (а не придуманный вами самими способ задавать функциональность системы), а ещё лучше -- дайте ссылку на ту книгу, из которой вы взяли конкретный использованный вами метод описания и сам вид этих диаграмм.

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

Контроль конфигурации

Конфигурация системы -- это то, из чего на какой-то момент времени состоит система. Конфигурация находится под контролем, если конфигурация определения системы соответствует конфигурации воплощения системы. Если какие-то части этих конфигураций не соответствуют друг другу, то говорят о конфигурационных коллизиях (например, если на принципиальной схеме изображено 12 насосов, а в реальной системе их стоит 11). В какой-то момент в США была отобрана лицензия атомной электростанции: из-за многочисленных модификаций оборудования чертежи перестали соответствовать реально установленному оборудованию, и эксплуатация станции в такой ситуации была признана небезопасной.

Контроль конфигурации обеспечивается тем, что конфигурация может быть собрана в любой момент. В частности, это означает необходимость знания о том, где лежат отдельные описания, а также необходимость контролирования разных версий отдельных частей описания: если в проект попали "чертежи с исправлениями после совещания 2 мартобря" и одновременно "чертежи, куда не успели внести исправления после совещания 2 мартобря", то ничего хорошего от использования такого проекта ждать не приходится.

Для того, чтобы обеспечить контроль за конфигурацией (configuration control), используется практика управления конфигурацией (configuration management). Эта практика системноинженерного менеджмента -- она занимается поддержанием целостности системы на протяжении всего жизненного цикла.

Заметим, что сама практика управления конфигурацией включает получение

TechInvestLab, 14 июня 2014

148

различных описаний. Так, именно в рамках этой практики выпускаются различные виды спецификаций закупаемого/изготавливаемого оборудования/изделий -- BOM (bill of materials, список комплектующих).

Для управления конфигурацией определения системы сейчас используют информационные системы управления версиями (в программной инженерии), PDM (product data management -- системы хранения информации проекта-design), PLM (product life cycle management: это PDM+система управления изменениями и поддержка интерфейсов в другие информационные системы других стадий жизненного цикла -- системы закупок, например), EAM (enterprise asset management, система управления активами -- используется для учёта установленного оборудования стадии эксплуатации).

Контроль конфигурации довольно сложен, ибо в больших системах непрерывно меняется как определение, так и воплощение системы.

Фокусирование определений системы

Говорят, что возможности фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта ("рабочую документацию", "рабочку"). Это нужно понимать так, что из свободы творить что угодно (свободы инженерных решений) возможности оставляют только то, что нужно стейкхолдерам. Если стейкхолдерам нужно лазерное медицинское оборудование, то вряд ли им нужны требования для автомобиля. Если требования

TechInvestLab, 14 июня 2014

149

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

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

Практики описания системы

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

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

TechInvestLab, 14 июня 2014

150

Требования

Два смысла слова "требования".

Термин "требования" имеет два разных смысла:

●Определение системы как "чёрного ящика" -- что требуется от целевой системы с точки зрения её стейкхолдеров (stakeholder requirements) и использующей надсистемы (system requirements). Обычно это спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д.).

●Любые определения системы ("чёрного ящика", "прозрачного ящика", на любых стадиях жизненного цикла), в которых присутствует деонтическая модальность (модальность долженствования).

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

"Требования" обычно означают совокупность отдельных "требований" (отдельных высказываний о системе).

Модальности в требованиях

Чтобы понять природу требований, нужно разобраться с модальными составляющими высказываний о системе (http://en.wikipedia.org/wiki/Modal_logic):

●нейтральные высказывания о мире, суть которых непонятна без указания модальности. Например, "длина дана как 16".

●алетическая (alethic) модальность, относящаяся к возможности существования. Обычно с алетической модальностью в связи 4D extensionalism связаны рассуждения про возможные миры (possible worlds): пока воплощения системы ещё нет, возможны варианты определений системы для разных возможных вариантов будущего воплощения системы -- но только один из них будет реализован "в железе". Например, "длина пусть будет 16" ("положим длину равную 16").

●деонтическая (deontic) модальность, относящаяся к обязыванию и дозволению. Например, "длина должна быть 16". Собственно, это и есть