Category: фантастика

Category was added automatically. Read all entries about "фантастика".

2021 год

lytdybr

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



Сверстал сегодня слайды на SECR'16 (http://2016.secr.ru/lang/en/program/agenda) -- в эту пятницу 28 октября у меня там
-- в 13:45 будет доклад "Практики жизненного цикла систем машинного обучения" (краткая суть доклада: всё пока плохо, в инженерии систем машинного обучения творческий беспорядок,-- но люди уже начинают задумываться о дисциплине),
-- в 15:00 двухчасовой мастер-класс "Системное мышление" (слайдов же я сделал на полдня, и даже с задачами, так что будем галопом по европам).

Объяснял сегодня родителям в чатике класса, что средний балл (который автоматом выдаёт "электронный дневник") никакого отношения не имеет к оценке в четверти -- оценки ставятся по "общему впечатлению", а не "округлением". То же относится, кстати, и к годовым оценкам. В плохих школах выставляют по "среднему баллу", а в нашем лицее и нашем классе есть те, у кого со всеми пятёрками четвертная 4 и есть те, у которых едва-едва над четвёркой было, но в четверти 5. Сугубо индивидуальный подход, и никакой "арифметической справедливости". Родители возмущались, радели за "объективную оценку" (по калькулятору? замером нейронной активности? я им дал ссылку на модифицированную таксономию Блума, это ж оценка педагогическая -- http://www.celt.iastate.edu/teaching/effective-teaching-practices/revised-blooms-taxonomy). У нас дома на оценки не смотрим, главное, чтобы материал знал по главным предметам, а по неглавным предметам было выше двойки (это для бюрократической безопасности, чтобы не вылетел).

Двигатели на антивеществе (испытания в космосе уже запланированы на 2019) -- это для меня стало неожиданностью, я как-то этого не отследил. Вот: http://www.nextbigfuture.com/2016/10/positron-dynamics-vision-of-antimatter.html, http://www.nextbigfuture.com/2016/10/positron-dynamics-near-term-work-to.html.

Неожиданно на 67 главе сегодня закончилась манга Fujiyama-san wa Shishunki -- http://mangapark.me/manga/fujiyama-san-wa-shishunki-ojiro-makoto. Такая атмосферная ecchi, которая ни разу не ecchi. Нарисована восхитительно. Есть очень немного "атмосферных" авторов, которые передают не столько сюжет (его обычно почти нет), сколько общее настроение -- причём мирное, а не suspense. В топах этой манге никогда не быть (там не стреляют, не дерутся, фан-сервис там совсем детский), но мне почему-то понравилось.

Завтра в Москве лучший ветер для работы ветрогенератора (это цитата из http://www.kakras.ru/interesn/wind.htm, там ещё хорошо про "ветер в ботфортах" опечатано), 7м/сек. Это "умеренный", поднимает пыль, бумажки. Качаются тонкие ветви деревьев и без листвы. Дым перемешивается в воздухе, теряя форму. У меня завтра 6 мероприятий, все в разных местах. Часть поэтому придётся пропустить, но всё одно -- весь день кататься с ветерком.
2021 год

Гарри Поттер, только круче, или к вопросу об однополых браках.

Жена долго смотрела какой-то сериал, в восторге приговаривая "Гарри Поттер, только круче". Я даже заинтересовался -- это, оказывается, семь серий Jonathan Strange & Mr Norrell http://www.imdb.com/title/tt2548418/ (IMDB 8.4, и впрямь круче Гарри Поттера).

А вот мне Гарри Поттера неинтересно читать-смотреть (я с трудом прочёл один томик и с трудом посмотрел один какой-то фильм, да и HPMOR не до самого конца одолел, хотя и много там прочёл). И к Джонатан Стрендж и мистер Норрел я тоже равнодушен. Лет двадцать назад я читал много всякой фэнтези, но потом как-то резко бросил. И на Гарри Поттера меня уже не хватило, как уже не хватит на эту новую его (ну, не его -- без разницы) инкарнацию.

Зато жена на дух и нюх не переносит мангу и аниме. Не то чтобы она была к ним равнодушна, она их активно не любит. Но у нас в доме войны на эту тему нет: каждый тихо предаётся удовольствиям в своём углу и это никому не мешает. Прозелитизм тут бесполезен, это ж понятно.

Всё-таки люди в их любви к разным видам художеств очень разные. Даже удивляюсь, почему из-за этого нет таких же жестоких религиозных сражений, как по поводу любви к разным языкам программирования (например, по ссылкам в http://justy-tylor.livejournal.com/238336.html в вежливой форме, а вот http://vit-r.livejournal.com/814184.html более жёстко), операционным системам (хотя сейчас эти войны поутихли уже -- а как рубились вокруг RT-11 против RSX-11!), а также сексуальной ориентации.

Ежели чего, то я функциональным языкам симпатизирую, но сам писать на них не буду. И я вполне за разрешение жениться кому хошь на ком хошь в США, хотя не считаю это таким выдающимся событием, чтобы аватарку красить. Вот если бы сразу разрешили браки M:N, это было бы другое дело. Хотя вру, с учётом унификации отношения к полу правильно писать браки N, где N больше или равно единице (женитьбу на себе любимом тоже нужно учитывать!). И ещё в это N вписать как потенциальных партнёров роботов и животных, которые сумеют выразить своё согласие.

Я и сам лесбиян: только женщинами обычно интересуюсь, к мужчинам безразличен, как и к Хаскелу, и к Гарри Поттеру. Но если кому мужчины, Хаскел или Гарри Поттер нравятся, то это его дело -- при этом неважно, какого он пола, возраста, расы, вероисповедания и на белковой ли он основе, и сколько их.
2021 год

Современный способ жечь книги: заблокирован сайт из-за текста "451 градус по Фаренгейту"

Сайт flibusta.net заблокирован в России за то, что на нём лежит текст книжки Брэдбери 1953 года выпуска "451 градус по Фаренгейту" (http://za-lib-ru.livejournal.com/197216.html). Это та самая книжка, в которой написано:
– А вы когда-нибудь читаете книги, которые сжигаете?
Он рассмеялся.
– Это карается законом.


Если воспользоваться Hotspot Shield, то сайт вполне доступен. Но вот Роберта Шэкли с него уже убрали ещё в 2013 (кстати, убрали тоже произведения 50-х годов, например, "Корпорация Бессмертие" 1959г.), "по требованию правообладателей" -- и ещё книги примерно 50 авторов (я проверил, всё так -- http://lenta.ru/news/2013/11/11/libraries/).
2021 год

Клавогонки три года спустя

Поскольку дитятка шлёпает уже где-то 40 ударов в минуту по-русски на тренажёре, я сегодня вывел его в люди: завёл ему эккаунт на http://klavogonki.ru/

Ну, и попробовал сам (прошлый раз я там был три года тому назад -- http://ailev.livejournal.com/778384.html). Оказывается, скорость моей печати как по-русски (слегка за 300), так и по-английски (слегка за 200) на обычных словарях за эти три года практически не изменилась. Вот уж не думал, что у меня такое постоянство...
2021 год

Гарри Поттер и методы рациональности

Прочёл 45 глав "Гарри Поттер и методы рациональности" -- текущую версию на русском, http://www.fanfics.ru/read.php?id=40982. На английском продолжающий публиковаться оригинал тут: http://www.fanfiction.net/s/5782108/1/Harry_Potter_and_the_Methods_of_Rationality, и в нём сейчас 85 глав, т.е. на русский пока переведена только половина. Автор -- Элизер Юдковский (http://yudkowsky.net/), тот самый, из Института Сингулярности. Текущий прогресс описан тут: http://hpmor.com/notes/progress-12-06-01/, и на этом же сайте http://hpmor.com/ теперь авторские заметки и разная другая информация, равно как и зеркало официальной версии этого фанфика.

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

Про Гарри Поттера и методы рациональности я читал с двойственным ощущением, примерно таким же, как читал романы Голдратта. Это, безусловно, "учебный роман". Художественную сторону учебных романов лучше бы не рассматривать вовсе: эмоции героев там полностью отвязаны от реалий жизни, и привязаны к акцентуации того, что хочет вам разумного, доброго и вечного сообщить автор. С другой стороны, там есть некий постмодернистский изыск, ибо отсутствие художественности частично компенсируется многочисленными отсылками: помянуты все, от Атридесов до Наруто в двух соседних строчках. Так что по художественной части ощущения -- ужас-ужас.

Основное блюдо -- это, как и объявлено, методы рациональности. Рефлексия, научный метод, рациональность этики, "что такое человек", как выжить человеку в человечестве, человечеству в бескрайнем космосе, и т.д. и т.п.. Учебник, он и есть учебник, для старших классов и первых курсов ВУЗов. Мне кажется, что я так или иначе знал существенно больше половины тех идей, которые появились в первой половине книжки. Но время от времени перечитывать такое мне кажется правильным. Так что не было ощущения потерянного времени.

Итого: читайте. Это ужас-ужас, но время не будет потеряно.
2021 год

Годовой отчет 2010 от vpri.org -- STEPS Towards Expressive Programming Systems

Они сделали что-то типа MS Office с куском операционки, только уложили огромный объем функций буквально в несколько тысяч строк кода -- http://www.vpri.org/pdf/tr2010004_steps10.pdf. Они подтверждают цель проекта: "то, что нужно типичному пользователю MS Office вместе с операционкой, должно уместиться в 20тыс. строк кода и работать на голом железе", "отношение числа строк нашего кода к типичному сегодняшнему коду должно быть как один к ста, тысяче, или десяти тысячам".

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



Они назвали эту систему Frank (от "Франкенштейн"), ибо задача этой системы -- показать, что собранное из предложенных языковых, алгоритмических и архитектурных идей программное изделие более чем живо и работоспособно.

Отчёт для NSF читается, как роман. Рекомендую (хотя многое в нём трудно понять, если незнаком с предыдущими работами -- тогда вам сюда: http://www.vpri.org/html/writings.php).

Я еще не видел работ, которые настолько бы явно выражали идею компактификации знаний, и так далеко в этом деле продвинулись.
2021 год

Об истории, или опять про гиперкниготексты, языки паттернов, модели-языки-нотации

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

Я сейчас пишу описание метода (одного из вариантов моделеориентированной инженерии требований), руководствуясь ISO 24744 (одного из вариантов ситуационной инженерии методов). Я в восхищении, потому как за многолетнюю жизнь консультанта давно не было формата, который заставляет продумывать важные даже не детали -- важные ключевые моменты! Формат ведет изложение, формат заставляет думать, счастье. Текст действительно начинает содержать суть дела. Все эти "языки паттернов" (в 2007 я писал "какую нужно писать книжку" на базе того, чем занимались в самой-самой первой wiki: http://ailev.livejournal.com/488174.html) отдыхают, это было лишь прошлое поколение этой формы. Следующее поколение стало менее человекочитаемое, но много более выразительное (в смысле "мысльдокументирующее", даже не "мысльпередающее").

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

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

"- Что же из этого следует?
- Следует жить, шить сарафаны и легкие платья из ситца.
- Вы полагаете, все это будет носиться?
- Я полагаю, что все это следует шить!"

Итого:
а) Описания в формате ISO 24744 все равно шьем, заранее зная, что оно не будет носиться людьми (чего не скажешь о компьютерах -- для них такое чтиво самое оно). Написание текста объявляется формой рефлексии, написанный текст -- справочником.
б) из текста готовится стандарт (еще более убогая форма).
в) нарративизация делается самыми разными другими формами -- монологичными отрепетированными рассказами с поддержкой слайдов a la kapterev; проведением семинаров, учебных курсов, лекцийт и других интерактивных форм; написанием романов (a la "Цель" Голдратта).

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

Я уже касался этой темы в 2003г. ("гиперкниготексты" 2003г., http://ailev.livejournal.com/103692.html) но тогда я думал о предписанных маршрутах в гипертекстах (каковая идея была реализована и с грохотом провалилась в "медиа-книгах для интернет-поколения" Sophie --http://www.sophieproject.org/, там, кстати, версия 2.0.5 вышла 6 апреля 2010). Теперь я думаю по-другому: в нотациях будут расцветать для разных целей сто разных цветов, и эти нотации будут порождать для разных целей сто разных отражающих одну и ту же модель документов. Мода сезона (разные представления для одного и того же представления кода/абстрактного синтаксиса, модели, онтологии) является не столько модой -- сколько периодом, когда много-много людей осваивают это новое веяние. Пройдет несколько лет, и мода пройдет, это будет обыденность, рутина, "просто культура" (см. про моды-поветрия в praxos.ru).

Чтобы не порождать новых сущностей, выражу это все в языке моделей-языков-нотаций из того же ISO 24744 (http://ailev.livejournal.com/817706.html)

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

В документах (коммуникативной форме, "на носителе" -- а хоть и на экране) язык (набор понятий предметной области), которым написана эта модель=гипертекст может быть представлен разными нотациями:
-- машинной (гипертекстовой или вообще в triple store -- некоммуникативной, или квазикоммуникативной, например в ходе data handover -- "передачи модели для учета в другую учетную систему"),
-- нарративной (образной на естественном языке, а то еще и с картинками. Ну, или вообще кино- или даже мультсценарий с раскадровками). И не нужно говорить, что "в этом варианте нужно много привнести помимо модели" -- принципы хороших историй достаточно жестки (ссылок на литературу даже не привожу), и это привнесение происходит по понятным законам. Нужно только сосредоточиться и сделать "как надо" а не "как получится",
-- отчетной (report, как в базах данных -- как раз вариант "гиперкниготекста", и его же я имел ввиду в своих недавних поисках генератора отчетов к базам данных -- http://ailev.livejournal.com/817413.html).

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

Об практику

Вчера я побывал на XVI Щедровицких чтениях (http://ailev.livejournal.com/802750.html). Главный вывод: никаких изменений с использованием слова "практика" для PraxOS, ситуационной инженерии методов и системной инженерии мы делать не будем. Пусть СМД-методологи сами разбираются в своем омонимическом компоте.

Сами методологи удивительно разнообразно трактовали слово "практика", подцепляя к нему самые разные рассуждения:
-- практика и деятельность одно и то же, но слова разные. Можно слово "практика" и не использовать (ибо деятельность и так устроена по норме). http://community.livejournal.com/methodology_ru/161656.html
-- практика -- это когда нормы СМД-методологической деятельности становятся мейнстримом;
-- практика -- это когда мы строим свою деятельность по построенным (а не нарисованным) схемам СМД-методологии (http://community.livejournal.com/methodology_ru/161894.html);
-- практика -- это когда мы решаем чьи-то производственные проблемы, а не проблемы СМД-методологии. Кто не практик -- тот не методолог;
-- практика -- это когда СМД-методолог построил схему, а другие люди ее используют (включая или не включая при этом самого схемостроителя);
-- практика -- это когда в ее основе лежат построенные схемы, а не отмоделированные "самовыросшие" ("моделирование vs дизайн"). И тут длииинная дискуссия, напоминающая дискуссию о "хранении традиции тайцзи", когда выясняется, что при моделировании можно резко улучшить какие-то характеристики деятельности, и это конфликтует с понятием "моделирования" -- фотограф не должен улучшать физиономию! И подобная же дискуссия про НЛП-моделирование и НЛП-дизайн и важности их различения. Так и тут: практика -- это когда по сдизайненной (построенной) схеме с улучшениями, или когда схема отражает as is (а даже и построенная)?
-- практика -- это когда решается проблема, независимо от [научного] предмета (а предмет меняется по мере продвижения в решении проблемы, это не является сменой практики);
-- практика -- это когда живем по всем схемам сразу, нельзя практиковать одну схему. Поэтому "практики инженерии требований" -- не бывает, практика "системной инженерии" с трудом проходит под этот критерий.
-- и так далее со всеми промежуточными остановками.

Я к микрофону не подходил, с места ничего не выкрикивал -- но был удостоен трех упоминаний в микрофон по поводу моего выступления на прошлых Чтениях (http://ailev.livejournal.com/664154.html, а в сборнике докладов Чтений 2008-2009г.г. опубликован полный текст транскрипта выступления и дискуссии), и еще один раз меня назвали косвенно "коллеги", когда речь зашла о моем кулуарном замечании про невозможность обсуждать все методологические схемы исключительно через призму "управления", не цепляя координации, организации, руководства и т.д. -- далее на мое это замечание было справедливо указано, что схемы эти при чисто-конкретно управленческом заходе становятся административными, и не более того.

Самое сильное заявление было сделано Петром Щедровицким в заключительном слове: как и предсказывал ГПЩ, методология сейчас является существенной составляющей интеллектуальной жизни. И СМД-методологи являются представителями только одной из методологических школ, есть и другие. Это СМД-методологам нужно признать, и начинать налаживать контакты с другими школами.

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

OIМ для моделеориентированной инженерии требований. Группы описания требований как product model.

Когда мы рассматриваем такой сложный продукт работы, как "требования", разным людям для работы с ним требуются разные группы описаний. Это означает, что информационная модель требований для работы с собой будет требовать разных языков представления, разного программного и методического. В частности, нужна классификация не только самих требований (функциональные, нефункциональные и т.д. -- см., например, http://ailev.livejournal.com/769827.html), но и групп описаний и адресуемых ими интересов.

Для требований в целом необходимо построить OIM (object information model -- из ISO 15926, метамодель -- из OMG, абстрактный синтаксис -- в language workbenches, "рабочую онтологию" -- из СМД-методологии), которая будет выражаться в разного сорта диаграммах (не обсуждается в ISO 15926, диаграммы -- в OMG, конкретный синтаксис -- в language workbenches, схемы в СМД-методологии), адресующих разные группы описаний. Эту метамодель нужно будет затем выразить в терминах объемлющей онтологии (онтологии интеграции данных) -- в нашем случае в ISO 15926.

Для этой работы выражения OIM требований в ISO 15926 нужно будет разобраться со специфически онтологическими вопросами: где мы говорим о создании экземпляра модели требований, согласно метамодели, а где речь идет только об уточнении требований, а где сами проектные решения или даже реализованная (т.е. реальная) по этим проектным решениям система (для случая системной инженерии требований эта работа выполняется прямо сейчас на базе находок стандарта ISO 24744 в проекте PraxOS -- http://praxos.livejournal.com/. Скорее всего, для требований придется делать аналогичный проект -- и решать абсолютно аналогичные задачи (ибо для требований, как и для методов могут быть использованы совершенно разные специфические предметные онтологии, зависящие от конкретной ситуации, к которой прилагаются "типовые" решения. Требования также могут быть повторноиспользуемыми и "типовыми", и т.д.).

Тут еще нужно подумать, как OIM собственно требований (в инженерии требований это OIM для product model) связано с OIM инженерии требований в целом как метода (где product model является только частью общей модели, а кроме того как минимум есть process model, project model, organizational model инженерии требований).

Поэтому я бы поставил в план работ по PraxOS переинтерпретирование моего позавчерашнего поста про моделе-ориентированную инженерию требований (http://ailev.livejournal.com/801113.html) в духе сказанного в данном тексте. Моделе-ориентированную инженерию требований нужно моделировать, сапожник должен быть в сапогах.

По итогам моделирования, конечно, нужно будет переопределено и уточнено содержание дисциплины "инженерия требований" (предыдущий немоделеориентированный вариант был собран тут: http://ailev.livejournal.com/769827.html) -- для современного варианта моделе-ориентированной инженерии требований (http://ailev.livejournal.com/801113.html, причем с учетом переинтерпретации из предыдущего абзаца. То есть работа будет весьма итеративной).

Затем все то же самое нужно будет проделать с OIM инженерии системной архитектуры -- с учетом того, что само понятие системной архитектуры как продукта работы намного хуже определено, чем понятие требований. Но глаза боятся, руки делают.
2021 год

Системная инженерия -- новый образ действий, или новый язык?

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

В этой контраргументации есть множество разных явных и неявных утверждений, каждое из которых нужно адресовать отдельно.

1. Системная инженерия -- это язык.
Да, системные инженеры хотели бы, чтобы это было так. В действительности же, в системной инженерии существует множество версий этого языка, обозначающих какой-то определенный набор практик. Вот слова прошлого президента INCOSE, Pat Hale (INCOSE INSIGHT, vol.12 issue 1 -- april 2009):
Мы инвестировали значительное время и энергию в выход на новые области приложения [системной инженерии]: потребительские товары, услуги, здравоохранение, общественный транспорт, если назвать для примера несколько, и нашли изобилие новых слов, аббревиатур и уточняющего жаргона для практик системной инженерии в этих областях, [так что] отсутствие какого-то "секретного кольца-переводчка" может быть существенным барьером на пути к нашему успеху.

Во время первой встречи Руководящего потребительского cовета INCOSE участники из разных промышленных предметных областей нашли, что несмотря на эквивалентность процессов их предприятий аналогам из системной инженерии, они используют отличную терминологию от той, которая используется в оборонной и аэрокосмической промышленностях; даже хуже, они нашли, что эта терминология отличается даже в разных подобластях промышленности и типах продуктов.

Для них было трудно обсуждать процессы друг с другом, не говоря уже о членах ядра INCOSE!

We have been investing substantial amounts of time and energy in an outreach to fresh application domains: commercial products, services, healthcare, public transit, to name just a subset, and finding that the profusion of new words, acronyms, and specialized jargon for systems engineering activities across these domains, and the lack of any “secret decoder ring,” may be the greatest barrier to our success.

During the first meetings of INCOSE’s Commercial Steering Board, participants from different commercial
domains found that even though their enterprise processes were equivalent to those of systems engineering, they used different terminology from that used in the defense and aerospace fields; even
worse, they found that terminology differed even across their own commercial subdomains and product types.

It was difficult for them to discuss processes with each other, let alone with the core INCOSE membership!
Выход Pat Hale видел в создании онтологий системной инженерии для разных промышленностей, а затем создание перекрестных ссылок в этих онтологиях, чтобы можно было делать "перевод" между разными языками.

Тем самым, системная инженерия, по мнению INCOSE, это все-таки не язык (понимаемый тут как терминология, способ описания), а практика (метод), набор практик (методов). Системная инженерия -- это особая деятельность, а уж каким языком или языками она описывается, можно обсуждать отдельно.

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

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

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

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

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

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