будем требовать полностью формальных (понятных даже компьютерам) суждений, но следование в рассуждениях предлагаемым схемам мышления необходимо. Системноинженерное мышление и деятельность в своей основе направляются привычными заученными схемами. Схемность мышления вовсе не означает его ограниченности. Просто объекты реального мира “подводятся под понятия” никогда не по одному, а целыми группами, связанными отношениями — то есть под понятия подводятся сразу ситуации, между объектами реального мира предполагаются прописанные в схеме отношения. Если схема кажется не подходящей для ситуации, её можно как-то адаптировать — создать новый набор фактов, более адекватно описывающий мир, более адекватно отражающий устройство мира. Но перед тем как это делать, научитесь сначала пользоваться уже наработанными схемами, не изобретайте велосипедов, не будьте Кулибиным-самоучкой. Вы вряд ли гениальный онтолог, поэтому смело вставайте сначала на плечи гигантов. И когда вы научитесь мыслить и действовать в рамках уже существующих схем, вы ясней поймёте их достоинства и недостатки, сможете эти недостатки преодолеть — предложите способы системноинженерного мышления лучше, чем имеющиеся сейчас, т.е. выпустите свой международный стандарт с вашей новой схемой, новым вИдением мира, новой онтологией.

Те, кто знают схему — это и есть “семантическое сообщество”. Они знают, что “команда применяет технологии”, как бы ни называлась “команда” (бригада, компания, рабочая группа”, как бы ни произносилось “применяет” (использует, опирается на, задействует, владеет), как бы по-разному ни появлялись бы в речи “технологии” (способы работы и инструменты, методы и их поддержка, производственная среда).

Итого: системноинженерное мышление — это умение рассуждать с использованием базирующихся на системном подходе и относящихся к инженерным проектам онтологических схем. Это умение подводить объекты реального мира под понятия на схемах и вести рассуждения с использованием этих понятий независимо от используемой в том или ином речевом сообществе терминологии.

Ситуационная инженерия методов

Для того, чтобы обсуждать, как устроено мышление системного инженера, нам нужно схемно/онтологически задать “теорию”, способ компактного описания того, что происходит в инженерных проектах: ввести основные понятия, которые должны присутствовать в нашем мышлении в каждом инженерном проекте. После этого мы получим способ обсуждать происходящее в разных проектах, используя эти основные понятия.

Описанием хода инженерной разработки (development process, engineering methodology) занимаются в рамках дисциплины “ситуационная инженерия методов” (situational method engineering). Она была основана в начале 80-х годов идеологами объект-ориентированного движения в программной инженерии, которые задали два основных структурированных (ибо неструктурированные в форме “просто текста на естественном языке” никто не отменял) вида описания своих способов работы:

●использование “языков паттернов” (ищутся некоторые “паттерны” — неформально определяемые способы решения задач, при этом каждый паттерн описывается по заранее известному шаблону, в который обычно входит описание проблемы и типовой способ её решения). Ассорти ссылок про языки паттернов тут: http://ailev.livejournal.com/487783.html. Паттерны — это чистой воды эвристики, никаких попыток выйти на какие-то более-менее

формальные “языки паттернов” не делалось. Само слово “язык” в словосочетании “язык паттернов” используется неформально (просто чтобы указать на то, что в проекте используются разные паттерны в разных сочетаниях, как слова из какого-то языка).

●ситуационную инженерию методов, как дисциплину. Стандарты описания метода в такой дисциплине обычно представляет собой “мета-модель”: описание языка, используемого для моделирования способов работы.

Donald Firesmith рассказывал, что он с друзьями занимались в начале 80-х объекториентированным программированием, что тогда было остромодно и ново. Как-то его вызвал начальник и сказал: “у тебя производительность программирования стала в последнее время в несколько раз выше, чем у остальных в нашей компании. Научи их своему методу работы”. Дональд пошёл на своё рабочее место думать над новым заданием, и понял, что не понимает — что такое “метод работы”, чему же он должен научить других сотрудников? Что происходит в ходе выполнения программистского проекта методом объектно-ориентированного программирования? Ему было понятно, что он работает уже не так, как до знакомства с объектно-ориентированным программированием, но как описать эту разницу в работе? Внешне ведь это выглядело просто как “сижу и думаю”, описывать нужно было не столько внешнее поведение, сколько происходящее “в мозгах” — да ещё и не само поведение, а “метод работы”, задающий поведение для многих и многих разных проектов.

Так он с друзьями начал разрабатывать новую дисциплину “инженерия методов”. Скоро выяснилось, что никакой метод работы не может быть перенесён из того конкретного проекта, в котором он был разработан, в другой проект. Ситуация (технология — инструменты и рабочие продукты, используемые в конкретном предприятии, и особенности целевой системы в конкретном проекте) меняла всё заранее записанное поведение-образец. И тогда инженерию методов переименовали в ситуационную инженерию методов (situational method engineering)

— чтобы подчеркнуть тот факт, что каждый метод работы зависит от ситуации, а между ситуациями выживает не сам метод как предзаданная последовательность операций, а только какие-то его части. В разных школах ситуационной инженерии методов эти части назывались компонентами/components, кусочками/chunks, ломтиками/slices и т.д. — главным образом компонентами выступали “артефакты” (рабочие продукты — над чем работаем), “процессы”, “инструменты” и т.д.

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

●первое, ориентированное на методологов, которым нужно было описывать методы работы и систематизировать эти методы работы. Это прежде всего стандарты OPF, ISO 24744 и OMG SPEM 2.0. Обзор этого первого поколения дан в http://www.jucs.org/jucs_16_3/situational_method_engineering_state/jucs_16_0 3_0424_0478_henderson.pdf

●второе, ориентированное прежде всего на удобство пользователей описаний

(инженеров), а не на методологов. Пока это поколение стандартов состоит из стандарта OMG Essence (http://www.omg.org/spec/Essence/ — версия 1.0

была выпущена в ноябре 2014).

Описание метода в настоящем курсе системноинженерного мышления

Настоящий курс системноинженерного мышления будет использовать адаптированный (существенно упрощённый, изменённый для работы с системноинженерными, а не софтверными проектами, а также переведённый на русский язык) стандарт OMG Essence — http://www.omg.org/spec/Essence/. Этот стандарт разработан в рамках инициативы SEMAT (http://semat.org).

Утверждение его прошло в консорциуме по стандартизации OMG (Object

Management Group, http://www.omg.org).

Адаптация для системной инженерии проводилась TechInvestLab

(http://techinvestlab.ru).

Обсуждение этой адаптации и перевода на русский язык проходило на заседаниях Русского отделения INCOSE (http://incose_ru.livejournal.com), идёт международная дискуссия, для чего был выпущен на английском языке продукт Русского отдления

INCOSE “Towards Systems Engineering Essence” — http://arxiv.org/abs/1502.00121

Стандарт предусматривает описание основных видов компонент метода (на языке компьютерного моделирования, текстовом языке и в графической нотации) и правила описания методов с использованием этих компонент. Стандарт определяет понятия “практики”, “метода”, “рабочего продукта”, “альфы” и т.д.

Кроме того, стандарт предлагает описание основных понятий программной инженерии как дисциплины (kernel, мы переводим это как “дисциплина”): те объекты, с которыми программисты встречаются практически в каждом инженерном проекте. Так, стандарт определяет такие “альфы Основы”, как “стейкхолдеры”,

“возможности”, “работы”, “команда” и т.д. Данный стандарт в настоящем курсе:

●Используется не целиком. Мы сосредотачиваемся в нём главным образом на альфах и немножко на рабочих продуктах, остальное игнорируем.

●Альфы инженерного решения мы заменяем с предложенных стандартом для программных проектов “требований” и “программной системы” на системноинженерные альфы “определение системы” и “воплощение системы”.

●Пересказан по-русски так, чтобы он был гармонизирован по терминологии с остальным содержанием курса (помним, что нас больше волнует “сообщество значений”, нежели “речевое сообщество” — мы за сохранение смысла и понимания, а не за сохранение слов-терминов. Но это не значит, что русскоязычная терминология нас вообще не волнует!).

Яблоки из жизни и яблоки из задачи

Вы будете удивляться, но это ключевой раздел всей книги: в жизни нет ни одного слова из книги, в книге нет ни одного слова из жизни — и в этом разделе поясняется, почему, и что с этим делать.

В основу описания инженерной деятельности мы положим такие теоретические объекты, как “альфы инженерного проекта”, тесно связанные между собой:

Главная трудность в понимании альф — это как основы системной инженерии (теория, содержимое нашей книги) связаны с практикой, с реальным миром. В реальном мире мы видим конкретные предметы, с которыми работает инженер: рабочие продукты (часто используемый синоним — “артефакты”, artifacts, т.е. предметы искусственного происхождения, work products). Эти рабочие продукты мы можем пощупать, пнуть ногой, указать на них пальцем. В реальном мире мы видим артефакты “яблоки” и дела с этими артефактами — “сосчитать яблоки”. Альфы представляют собой те объекты, которые описываются дисциплиной (теорией) — “количество предметов” и “сосчитать предметы”, если вернуться к примеру с яблоками. Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком варианте:

пришла в ... школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и ещё пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь — раз–два– три — три яблока, а здесь вот — раз–два–три–четыре–пять — пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий — рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот–де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие — это яблоки из задачи». — «Да, а что?» — «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладёте реальные яблоки — что с ними надо делать? Их надо есть. А