Как создать слона, стандарты системноинженерного мышления, ISO 81346 и схема метро

Как съесть слона? По кусочку за раз: при таком подходе можно ещё и распараллелить это удовольствие на целую бригаду едоков. Ломать -- не строить. Создать слона по кусочку за раз так легко не получится: при проектировании по кусочкам сложить работоспособного слона очень трудно -- то печень забудут, то непонятно как работать с перегревом, то кости в ногах не будут выдерживать массы туши. Но интуитивно понятно, что придётся таки слона для его создания как-то делить на кусочки. А потом работать с этими кусочками по принципу "по кусочку за раз". Что это за "создавательные кусочки"? Слон -- сложная система (напомню, что "сложная" система это не такая, в которой всё от всего зависит, а такая, в которой все эти зависимости заведомо не помещаются в человеческую голову и нужно придумывать разные способы описания, удерживающие работоспособное целое). Слона создают по интересу (concern) за раз -- это принцип разделения интересов (separation of concerns), сформулированный Dijkstra (http://en.wikipedia.org/wiki/Separation_of_concerns). Краткая суть этого принципа: обо всём нужно думать по отдельности, сразу обо всём думать не получится. Чтобы властвовать над определением системы, надо его разделять. Все определения системы (альфы -- требования, архитектура и т.д.) и связанные с этими определениями описания (спецификации требований, архитектурные диаграммы и т.д.) как раз отражают этот принцип. Каждое действующее лицо (stakeholder) имеет какой-то интерес к системе, и его поэтому интересует про систему не всё, что можно, а только то, что ему нужно. По одному интересу за раз, и так пока не удовлетворим всех стейкхолдеров. Это суть системного подхода, системноинженерного мышления: -- системные холархии (матрёшки из холонов -- части и целые). Нет целого без частей, нет частей без целого. -- каждое действующее лицо интересуется чем-то своим, что важно для его действия. "Система в глазах смотрящего" (вернее, действующего): деятельностный подход. -- определение системы множественно по своей природе, его составляющие необходимы для удовлетворения разных интересов разных действующих лиц. -- описаний системы ещё больше (в какой-то презентации по OMG Essence указывается, что сжатие информации при переходе к обсуждению в "альфах" по сравнению с обсуждением в "рабочих продуктах" составляет 1:10 -- о состоянии альфы мы узнаём подробности по десятку рабочих продуктов). -- все эти определения и описания создаются (изменяются, эволюционируют) в ходе жизненного цикла системы. Похоже, что минимальный набор более-менее концептуально совместимых международных стандартов современного системноинженерного мышления таков: -- обобщенный с архитектурного описания до описания определения системы ISO 42010: множественность описаний и деятельностный подход. Это "поворот мозгов" от редукционистского подхода одного всеохватного описания к системному подходу, подразумевающему множественность связанных описаний. -- обобщенный с программной до системной инженерии OMG Essence: описание жизненного цикла (системноинженерный менеджмент). Метод контрольных вопросов в управлении жизненным циклом. -- ISO 81346 для минималистичного описания и именований. Это фундамент для управления конфигурацией системы. -- ISO 15926 для моделирования данных развёрнутых описаний. Обеспечивает федерирование развёрнутых описаний. Этот небольшой набор стандартов и нужно гармонизировать, на этой основе и нужно создавать учебные курсы, на этой основе и нужно консультировать предприятия. Забавно, что тусовки (community of practice) вокруг этих стандартов очень мало знают друг о друге -- несмотря на всю идейную их близость. Я писал тут про все эти стандарты, кроме ISO 81346. Это относительно свежий стандарт, 2009 года. Стандарт ISO 81346 претендует на роль самого минималистичного метода описания системы. В нём определены принципы создания системы справочных обозначений (reference designation system, RDS -- слово "система" тут означает "систематичность", а не целевую систему) целевой системы. Эта система справочных обозначений отражает самое существенное в основных трёх стилях (function, product, location): имена объектов и их место в холархии (разбиения, т.е. отношения "композиции" или "часть-целое"). Функция, конструкция и размещение (модули, компоненты и места; функции, продукты и места: эта основная троица в разных школах обсуждается под разными именами) отражают основные, хотя и не все, стили определения инженерной системы. Подробно этот вопрос разбирается в программной инженерии (например, я упоминал книжку http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a -- на неё, в частности, ссылается ISO 42010). Но ISO 81346 в минималистичном варианте проводит эту мысль и для "железных" систем. Неправильно понимать этот стандарт как "принципы создания кодировок", не в кодировке/именовании дело. Это именно стандарт принципов минималистичного описания инженерной системы. Главное достоинство этого стандарта в том, что в предлагаемых им описаниях выкидывается 99.9% информации о системе, но оставшиеся 0.1% (только имена объектов и отношения "часть-целое") оказываются крайне полезны. Вот тут можно почитать об этом стандарте подробнее: http://81346.com/english/?page_id=117. Схема метро приводится в объяснительных материалах к этому стандарту как пример того, как радикальное упрощение описания системы резко повышает его полезность. Всем знакомая "схема метро" впервые была придумана в 1931 году (http://en.wikipedia.org/wiki/Tube_map, http://en.wikipedia.org/wiki/Harry_Beck и чудесные фильмы краткий http://www.youtube.com/watch?v=Bg3pfUqdLp4 и длинный http://www.youtube.com/watch?v=1xmOpyv5NuI). Автор схемы метро заметил: расстояния и длины не важны (по большей части), направления неважны (по большей части), пересадки важны. Один аспект, один интерес, одно описание за раз. Схема московского метро отражает сегодня те же принципы (http://metro.yandex.ru/moscow/). Вот краткое видео, подчёркивающее ту же мысль: важность бедных информацией представлений -- http://www.youtube.com/watch?v=W4A1Dnlv8h0