Если говорить о близких к SEBoK русскоязычных учебниках, то их не так много. Академическое изложение предмета системной инженерии вы найдете в учебнике Александра Косякова и др. «Системная инженерия. Принципы и практика», переведенного с английского языка под редакцией Виктора Константиновича Батоврина. В МФТИ издано учебное пособие «Базовый курс системной инженерии», написанное Виктором Юрьевичем Николенко.
Что касается книги, которую вы читаете сейчас, то она никак не может быть названа учебником, однако представляет собой до боли актуальный кейс пример использования системной инженерии в реальном проекте с множеством жизненных ситуаций, о которых обычно нигде не пишут. Опыт преподавания системной инженерии в Уральском федеральном университете (УрФУ) показывает, что для уровня системно-инженерной магистратуры катастрофически не хватает сборников кейсов, шаблонов, примеров и т. д. и т. п. В этой книге я постарался собрать те частные методы описания (методики, техники, методы, фреймворки и др.), а также инструменты, которые я сам чаще всего использую в работе. Так проще объяснять мне, и так быстрее системная инженерия становится понятна моим студентам.
На практике чаще всего встречаются следующие системно-инженерные роли:
системный инженер отвечает за весь жизненный цикл системы;
системный аналитик отвечает за требования к системе;
системный архитектор отвечает за системную архитектуру;
системный тестировщик отвечает за тестирование системы;
системный администратор отвечает за обслуживание системы.
Системно-инженерная роль подразумевает не только ответственность, но и способность (компетенцию). Таким образом, чтобы избежать путаницы, сразу условимся, если, например, главный конструктор (по должности) отвечает, в том числе, за требования, но не обладает компетенциями системного аналитика (то есть не знает соответствующих дисциплин и не имеет нужного инструментария), то его нельзя называть системным инженером (по роли).
Примерами систем могут быть: автомобиль, самолет, система документооборота, завод, смартфон, месторождение полезных ископаемых, клиника и т. д.
В этой книге мы уделим внимание ролям системного аналитика и системного архитектора, а предметную область выберем самую актуальную Интернет вещей.
Часть 1. Тренировка на салфетках
Глава 1. Разделение зон ответственности
Давайте представим, что вы попали в новую организацию, и вам предстоит выполнять какую-то новую работу. Первым делом, вы понимаете, что ваша должность не имеет ничего общего с теми задачами, которые вам реально нужно решать в этой организации. Например, вы устроились на должность системного аналитика в ИТ-компанию. В лучшем случае, вас попросят первые три месяца доделывать прошлогодние отчеты по каким-нибудь псевдопроектам, потому что ни у кого не доходят руки. И вообще, дело понятное, что удел новичков залатывать дыры.
Работа над прошлогодним отчетом, впрочем, как и любая другая работа, падающая на плечи новичка, является отличным поводом к моделированию вашей организации. На языке системной инженерии вы имеете ценнейшее время, чтобы определить обеспечивающую систему для будущих проектов, то есть ту систему, которая будет, например, проектировать и воплощать целевые системы.
Работа над прошлогодним отчетом, впрочем, как и любая другая работа, падающая на плечи новичка, является отличным поводом к моделированию вашей организации. На языке системной инженерии вы имеете ценнейшее время, чтобы определить обеспечивающую систему для будущих проектов, то есть ту систему, которая будет, например, проектировать и воплощать целевые системы.
Целевой системой будем называть тот конечный продукт, подлежащий эксплуатации, за работу над которым инженерным организациям платят деньги или выдают еду (в зависимости от места работы).
В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов команды, как стейкхолдеров.
Присутствуя на периодических совещаниях, вы скорее всего заметите, что руководитель проекта очень часто берет на себя роль системного архитектора, продавца и даже заказчика. Системный архитектор порой ведет себя как менеджер. А еще иногда приходит какой-нибудь заместитель директора, который к проекту относится очень условно, и начинает констатировать конструкторские решения, потому что он человек опытный.
Присутствие различных стейкхолдеров на совещании это, действительно, очень хорошо, но только в том случае, когда они свою «стейкхолдерскую» роль осознают и не играют других ролей, и другие им не потакают. Замдир может своим авторитетом полностью перегнуть палку, в результате чего вся команда согласиться на совершенно непродуманное решение, а сам этот замдир, в силу своей занятости, на совещаниях в ближайшие полгода не появится. В большинстве случаев может оказаться, что он, вообще, стейкхолдером не является.
Если у вас в команде есть системный архитектор, то конечное решение о системной архитектуре принимает именно он, а не коллективный разум программистов. На деле мы всегда наблюдаем такую картину, что рядовые инженеры с удовольствием готовы порассуждать над вариантами архитектуры. И вот эти самые абстрактные рассуждения, иногда претворенные в бумажных почеркушках, и любят называть системной архитектурой.