Оглавление
Благодарности
Я благодарен читателям «Хабра» @avshkol, @Guestishe, @steb за интересные отзывы на мою статью «Инженерная фантастика»!
Александр Школьников @avshkol обратил моё внимание на то, что говоря об инженерии нужно тут же упомянуть изменение материальной среды. Я с ним полностью согласен и в нижеприведённой статье продвигаю эту мысль: Инженерия это действие, умение преобразовывать материю.
С читателем @steb мы горячо обсудили отношения между инженерией и наукой. Он полагает, что инженерия — это часть науки. Я с ним не согласился и высказал противоположное мнение о том, что инженерия это отличная от науки деятельность. Моё несогласие вынесено в название статьи, а текст настоящей статьи это аргументы в пользу моего (субъективного и никому не интересного) мнения.
Введение
Довольно часто в публикациях слышны стоны инженеров о том, что другие их не понимают. Сплошь и рядом от знакомых можно услышать: «Почини утюг, ты ж программист!». А от работодателей: «Инженеры, перетащите шкаф! Всё равно сидите!».
Мы в киберклубе на очередной сессии за рюмкой чая тоже решили «постонать» и выслушать жалобы друг друга о том как нас, бедных и несчастных инженеров, никто не жалеет и не понимает. Первый же вопрос поставил нас в тупик. А мы сами-то себя понимаем? Как задать вопрос об инженерии? Инженерия это «что» или «как»?
С научной точки зрения вопрос следовало бы сформулировать так: «Инженерия это что?». И получить ответ: «Это то, чем на работе заняты инженеры». И в этом случае починять утюги и перетаскивать шкафы вполне себе инженерия. Но именно такой ответ — а соответственно и вопрос — и не устраивает некоторых инженеров.
С инженерной точки зрения вопрос звучит так: «Инженерия это как?». Один из приемлемых для инженеров ответов: «Это решать проблемы клиентов, эвристически подбирая методы проектирования для собственных суждений».
Как только мы изменили постановку вопроса, то по давней русской традиции сразу нашли кто виноват и поразмыслили что делать.
Виновата, естественно, наука! Это она приписывает себе достижения инженеров. Можно подумать что все эти утюги и шкафы вокруг нас сконструировали и произвели учёные! Да что там утюги! Все блага цивилизации созданы инженерами!
А делать нужно то, чем занимались модернисты прошедшую сотню лет — решительно отмежевать ненавистную науку от любимой инженерии. «Инженерия — не наука!», — объявили мы манифест нашего киберклуба.
Инженерия — не наука!
Провозгласив манифест, мы по православной научной методике отделили зерно инженерии от плевел науки. После чего подытожили найденные отличия:
Научная проблема — это незнание. Невежественному не хватает знаний. Инженерная проблема — это неумение. Некомпетентному не хватает умений.
Наука — это корпус теоретических, пропозициональных знаний. Инженерия — это корпус практических умений.
Наука — структура (система) знаний. Инженерия синкретическое пространство методов и эвристик.
Наука связана с обобщением, универсальностью, определённостью, вневременной абстрактностью. Инженерия действует в условиях случайности, вероятности, частности и конкретности.
Наука доверяет объективным знаниям и применяет их для верификации других объективных знаний. Инженерия доверяет субъективному опыту и применяет его для преднамеренного достижения цели.
Наука нацелена на истину. Инженерия нацелена на успех.
Наука проявлена в словах. Инженерия проявлена в действиях.
Обладатель научных знаний это человек информированный (Homo informativo). Обладатель инженерных навыков это человек умелый (Homo faber).
Наука желает понять Вселенную. Инженеры активно преобразуют Вселенную.
Наука это предмет, который описывает предметы. Инженерия это действие (техника), помогающее действию (практике).
Наука исследует «что есть (что существует)». Инженерия достигает «как будет».
Учёные — это патологоанатомы природы. Инженеры — это опекуны, заботящиеся о природе.
Наука погружена в прошлое, а инженерия живёт будущим.
В общем, инженерия — это другое!
Инженерные умения генерирует практика, а не чтение теории. Для любого проекта важно конкретное умение инженера достичь успешного результата в конкретной ситуации, а не общие знания о Вселенной. От инженера требуют разумных действий, а не энциклопедического попугайничества. Важно делать, а не говорить об этом.
Научная и инженерная проблемы
Рассмотрим отличие научной проблемы от инженерной проблемы. При этом, основное внимание, естественно, уделим тонкостям инженерных проблем.
Начнём с определения научной проблемы:
Научная проблема — это теоретическое суждение, отражающее противоречие, несоответствие имеющегося уровня научного знания с потребностями науки или практики. [1]
Это знание о незнании как результат:
неполноты и недостоверности имеющихся в распоряжении учёного фактов;
отсутствия корректных и надёжных методов исследования;
недостаточного уровня обобщения и теоретического осмысления.
Продолжим определением инженерной проблемы и подробными пояснениями к приведённому определению.
Инженерная проблема — понимание организацией:
невозможности преодолеть самостоятельно технические трудности практики;
необходимости сторонней технической помощи.
В данном определении следует понимать под:
«Пользователями» — любую группу операторов, использующих технику. Например, производственный поток или цех, управляющее или обеспечивающее подразделение.
«Самостоятельностью» — наличные ресурсы, умения и опыт пользователя.
«Практикой» — продукт, услугу, проект, процесс, управление и любую другую деятельность пользователей.
Инженерная проблема, как правило, приводит к фактическим или потенциальным инцидентам, препятствующим деятельности пользователя. У организаций возникают угрозы, отклонения от производственных и договорных обязательств.
Анализируя сложную проблему инженер:
выделяет проблемную область;
определяет проблемное пространство;
выбирает проблемное состояние;
оценивает проблемный риск;
составляет отчёт об инженерной проблеме.
Проблемная область — область деятельности, в которой возникла проблема.
Выделение проблемной области позволяет инженерам конструировать модели деятельности в этой области и проектировать технику, которая позволит преодолеть возникшие трудности и инциденты.
Проблемное пространство — концептуальная или формальная область, которая определяет все возможные состояния инженерного объекта.
Анализ проблемного пространства позволяет инженеру выбрать лишь те состояния инженерного объекта, которые будут учтены при проектировании техники. Выделяя проблемное пространство из проблемной области, инженер снижает уровень сложности проблемы.
Редукция проблемы — способ сведения сложной проблемы к более простой.
Но даже редуцированное проблемное пространство инженер может воспринять как сложное для понимания. В этом случае инженеры применяют замену сложной проблемы набором более простых проблем.
Декомпозиция проблемы — способ разделения сложной проблемы на ряд относительно простых проблем.
Декомпозицию проблемы можно осуществлять путём замены:
общей проблемы рядом частных проблем;
целой проблемы структурой частей этой проблемы.
Следует помнить, что при декомпозиции происходит потеря тех участков пространства проблемы, которые не вошли в набор простых проблем (моделей).
Полная картина снижения уровня сложности — и потерь сведений о ситуации, — выглядит следующим образом (Рис.1).
Упрощение сложной проблемы до приемлемого уровня позволяет инженеру определить проблемное состояние техники.
Проблемное состояние — состояние техники, неизвестное оператору.
Обязанность инженера — решить, что делать с проблемным состоянием техники. Инженеру следует не упускать из вида то, что проблема у пользователя, а не в технике.
Если инженер решит, что проблемное состояние это полезное действие, тогда следует научить оператора использовать эту возможность или автоматизировать действие. Автоматизация оставит состояние, но исключит необходимость обучения оператора техники. Отдельный случай проблемных состояний — это автономные модули и подпроцессы. Оператор может не знать что и как выполняет автономный подпроцесс. Инженеру следует помнить, что модульность техники порождает проблемные состояния, т.е. формально снижает управляемость, прозрачность, понятность деятельности для операторов технической инфраструктуры.
Если инженер решит, что проблемное состояние это негативное действие — например, поломка оборудования, — тогда следует ликвидировать это состояние — например, починить оборудование.
Инженерия это не только реактивная, но и проактивная деятельность. Инженеры обязаны не только реагировать на возникшие фактические трудности, но и прогнозировать потенциальные угрозы будущего. Для этого инженеры:
Организуют сбор и журналирование данных о деятельности техники организации.
Определяют допустимые пороги, которые не должна превышать техника. Например, вводят температурный порог нагрева процессора. Состояния выше этого порога служит фактором риска возникновения инцидента (неправильной работы или выхода из строя).
Сопоставляют журнальные данные и пороги для оценки рисков.
Часто инженеры забывают, что журналирование это сведения о людях, а не о «железе». Собирая данные, инженер строит картину деятельности организации. В современной инженерии необходимо учитывать социотехнический аспект. Говоря «техника», следует подразумевать «люди», а говоря «организация», следует подразумевать «техника».
Динамика состояний техники, отражаемая журналами, позволяет инженеру оценивать потенциальные риски возникновения проблем у пользователей.
Триггер инженерной проблемы — значение состояния техники, превышающее допустимый порог.
Проблемный риск — вероятность возникновения инженерной проблемы (инцидента).
Анализируя данные журналов, инженеры выявляют проблемы фактические или потенциальные. Результат анализа сводят в отчёт об инженерной проблеме.
Отчёт об инженерной проблеме — документ, идентифицирующий инженерную проблему, возникшую в деятельности оператора техники.
В отчёте об инженерной проблеме содержит:
сведения о возникновении подобной проблемы в прошлом;
сведения о факте возникновения проблемы в настоящем;
прогноз, предположение о риске появления проблемы в ближайшем будущем.
Подобная структура отчёта позволяет судить о проблемной области, регулярности инцидентов, качестве инженерного обеспечения. Например:
Полное (абсолютное) решение проблемы, ликвидация трудности оператора техники. Однократное выявление инцидента и однократное проектирование решения проблемы.
Частичное решение проблемы, регулярное преодоление трудности оператора техники. Периодически возникают вариации одной и той же проблемы у одних и тех же операторов с одной и той же техникой.
Отсутствие решения проблемы. Инженерами не предложены решения однократного или многократных инцидентов. У пользователей остались трудности оперирования техникой при осуществлении деятельности.
Понятия, описанные выше, позволяют инженеру получить качественное описание проблемы и перейти к определению количественных измерителей.
Параметризация проблемы — математическое представление проблемы, включающее конкретный набор определяющих параметров.
Сложные проблемы содержат более одной параметризации. Для разных ситуаций используют разные наборы параметров.
Опираясь на качественные и количественные модели, инженеры приступают к проектированию решения.
Решение инженерной проблемы — проектирование действий, которые приведут пользователя техники к успеху.
Проектирование решения инженерной проблемы — недетерминированный процесс. Это не алгоритм, а синкретизм набора методов. Порядок применения методов определяет инженер в каждой проектной ситуации. При этом инженер может неоднократно применять один и тот же метод. Например, при попытке проектирования станет ясно, что доступные ресурсы не позволяют достичь поставленной цели. Попытка переформулировать цель ведёт к необходимости повторного анализа области деятельности и проблемного пространства.
Сложные инженерные проблемы не решают в одиночку. Обычно задействована группа специалистов. Совместная (коллективная) инженерия требует применения организационных моделей. Например, модели 8D.
Что же служит критерием успеха для самого инженера? Какова цель его усилий?
Цель решения инженерной проблемы — приемлемое для пользователя техническое действие.
Под «техническим действием» следует понимать не ручную операцию пользователя, а действие с применением техники (оборудования, устройств, программного обеспечения и т.п.).
Проще говоря, владельцем и научной, и инженерной проблемы всегда выступает пользователь, который в своей практике столкнулся с трудностью. Отличие в том, как пользователь строит запрос:
Просьба в помощи решения научной проблемы: «Я не знаю что это и почему это так. Расскажите!».
Просьба в помощи решения инженерной проблемы: «Я не умею это делать. Научите как это сделать! А лучше — сделайте это вместо меня!».
Научные знания и инженерные умения
Доводы об отличии инженерии от науки навели на мысль о том, что инженерия — это автономное пространство умений инженера. Морфологию этого пространства можно представить в виде классификации областей и классификации типов инженерных умений.
Классификация областей инженерных умений:
Концептуальная инженерия. Онтология среды и гносеология инженерных объектов.
Инженерия требований. Критерии успешности проекта. Целевые количественные параметры, выведенные из целевых качественных критериев.
Инженерия данных. Качественные и количественные данные практики. Принятые константы. Допустимые отклонения. Условия эксплуатации техники и факторы безопасности эксплуатации (практики).
Эвристики. Практический опыт, эмпирические правила и оценка.
Методы рассуждения. Логические и математические модели, расчётные схемы, основанные на успешных реализованных проектах.
Методы проектирования. Инструментарий.
Организованность:
Управление потоком проектов, придерживаясь ритма и сроков достижения промежуточных целей.
Инженерная политика. Взаимодействие с внешними сторонами (заинтересованными лицами, заказчиками, поставщиками, подрядчиками). Умение всеми сторонами проекта выполнять свою часть обязанностей.
Классификация типов инженерных умений:
технические умения:
конструкторские умения (конструировать предметы);
технологические умения (производить артефакты);
организационные умения:
социальные умения (общаться, взаимодействовать);
экономические умения (управлять ресурсами);
политические умения (следовать правилам);
культурные умения (следовать ценностям).
Просматривая классификацию инженерных умений, закрадывается крамольная мысль о том, что теоретическое вузовское образование не так важно для практикующего инженера. Требование диплома в вакансии работодателя вовсе не означает, что вузовские знания будут востребованы и применены в проектах организации. Требование наличия диплома — это всего лишь проверка настойчивости, целеустремлённости, хитрости и изворотливости кандидата. Не более!
Правильность и синкретизм
Научный и инженерный подходы отличны друг от друга.
Научный подход условно можно назвать принципом достаточного основания. Согласно этому принципу у всего происходящего есть определённая причина. Следовательно, у каждой проблемы существует одно «правильное» решение. С математической точки зрения принцип достаточного основания это поиск значений переменных в системе линейных уравнений.
Инженерный подход условно можно назвать принципом инженерного синкретизма. Согласно этому принципу для каждой проблемы существует множество возможностей её решения. Если возможности имеют одинаковую вероятность успеха, можно принять любую из одинаково допустимых альтернатив.
Именно поэтому инженерия это поиск пространства допустимых решений, а не поиск причин. С математической точки зрения инженерный синкретизм это поиск области допустимых значений переменных в пространстве нелинейных неравенств.
Детерминизм и эвристика
На основании доводов об отличии инженерии от науки и морфологии умений можно определить, что:
Инженерия представляет собой желательное для пользователей техники изменение окружающей среды в условиях неопределённости этой среды и ограниченности доступных ресурсов.
В народе распространён миф, в который верят даже начинающие инженеры о том, что инженерия это рациональное решение проблем. По секрету сообщу вам — это не так! И всё потому, что и формулирование проблемы, и поиск решения проблемы недетерминированы. В начальной стадии проекта ситуация вообще неявная и неопределённая. Инженеры прилагая большие усилия выдавливают из заказчика кое-какие сведения, которые кое-что проясняют в ситуации. После этого инженеры превращают смутные требования в замутнённые технические задания, по которым проектируют мутные решения. Другими словами:
Инженерный метод — стратегия поиска наилучшего из возможных вариантов изменения плохо понимаемой ситуации в пределах доступных ресурсов.
Немного подробнее о недетерминированности инженерии.
В предыдущей статье, говоря об искусстве инженерии, я рассказывал об умении общения инженеров с заинтересованными лицами. Общение предполагает умение инженера из множества букв, которые наговорит клиент, сформулировать суждения на инженерном языке. Инженер, как врач, должен уметь выслушивать жалобы пациента, ставить диагноз и прописывать волшебную техническую пилюлю. К каждому клиенту нужно найти подход, установить устойчивый контакт, разговорить… Аналитика это не столько систематизация и структуризация данных, сколько поиск эвристик получения как можно большего количества разнообразных сведений о ситуации.
Получив множество несовместимых обрывков сведений о ситуации, инженеры начинают думать о том что с этим счастьем делать. Мыслительная эквилибристика, которую инженеры называют осмыслением, представляет собой попытку поместить бесконечно сложную проблему в бесконечно простой человеческий разум. Естественно, проблема в разум не влезает! Но у инженеров для данного фокуса есть два туза в рукаве — эвристики абстрагирования и идеализации.
Абстрагирование игнорирует некоторые аспекты реальности, несущественные с точки зрения инженера в данной ситуации. Далее инженер осуществляет проектирование лишь с ограниченным количеством аспектов.
Идеализация заменяет сложные аспекты реальности упрощёнными представлениями (образами, моделями).
В разделе выше мы обсуждали принципы достаточного основания и инженерного синкретизма. Эвристики попадают в область инженерного синкретизма. Их невозможно доказать с помощью научной (математической) логики. Тем не менее инженеры их успешно используют. И обоснованием эвристики служит не логика, а опыт успешного внедрения техники в прошлом. Фактически каждый инженер владеет уникальным набором эвристик. А ещё он владеет метаэвристиками, позволяющими в каждом конкретном проекте выбирать комплект эвристик из синкретического пространства методов.
Почему инженеры используют эвристики большинство из которых ошибочны и иррациональны? Потому что эта инженерная иррациональность реально помогает выстраивать техническую рациональность! Именно эвристики помогают преобразовать неявные, неполные, нетехнические и противоречивые высказывания заказчика в формализованную инженерную проблему, которой понятно как управлять и как достигать жизнеспособного технического решения. Инженер самостоятельно дополняет пустоты требований таким образом, чтобы они не противоречили желаниям заказчика. Именно этот творческий процесс называют проектированием.
Единственный крупный недостаток эвристик в том, что этому невозможно научить чтением научной литературы. Эвристики приходят только с опытом.
Инженерия — не технология!
Вспомним этимологию сложного слова «технология»:
техн- (греч. τέχνη) — искусство, мастерство, техника;
-логия (греч. λογία) — наука, учение, знание.
Логия (от греч. lógos — слово, учение) — часть сложных слов, означающая: учение, знание, наука.
Пример, 260 наименований наук, содержащих часть «логия».
Корнесловное значение термина «технология» — наука о технике. Более строгое определение термина:
Технология — научное описание техники (средств и способов деятельности), применяемой организациями в определённой области деятельности.
Соответственно:
Информационная технология — это наука об информационной технике — структурированные знания о технике, — применяемой организациями для преобразования информации.
В свою очередь:
Информационная инженерия — это управление техникой преобразования информации.
В этом определении под управлением техникой следует понимать управление жизненным циклом:
средств преобразования информации: проектирование, производство, эксплуатация, обслуживание, демонтаж устройств;
способов преобразования информации:
проектирование, программирование, эксплуатация, обслуживание, демонтаж программного обеспечения;
проектирования, обучение, применение, повышение квалификации, навыков технического персонала.
При этом непосредственное управление информацией относят к управлению основной деятельностью, а не инженерии. Т.е. процессы проектирования, структурирования, применения, обслуживания, архивирования информации (данных, знаний, документации и т.п.) выходят за пределы ответственности информационной инженерии.
Проекты информационной инженерии предусматривают автоматизацию (технизацию) деятельности заказчика. Хотел бы я посмотреть на лицо заказчика, который ожидает практических мер по «расшивке узких мест производства» (инженерию), а проектировщики приносят ему пачку бумаги с подробным описанием применяемой им техники (технологию).
В дополнение к информационной инженерии следует сказать пару слов о программной инженерии.
Программная инженерия — применение инженерии к программному обеспечению. [3]
Другими словами, программная инженерия применяет для управления жизненным циклом программного обеспечения:
умения инженера — методы, знания, опыт;
технику инженера — технические средства и способы (MBSSE, CASE, SEE).
Попутно хочу обратить внимание, что в последние годы методы информационной и программной инженерии вошли в состав переживающей бурное развитие финансовой инженерии. Инженерные методы и эвристики нашли применение в финансовой практике.
Для тех, кто в последнее время стремился «войти в АйТи» по секрету скажу: «Вы вошли не в ту дверь!». За чтение научной литературы (см. определение информационной технологии) денег не платят. Надо стучать в двери с надписями IE (Information engineering) и SE (Software engineering). Именно там неплохо оплачивают инженерные умения проектировать и обслуживать информационные системы и программное обеспечение.
Инженерия — не система!
О синкретизме инженерных методов я уже писал в статье «Инженерная фантастика». Повторять не буду. Посмотрите, если интересно.
Вы будете долго смеяться, но системная и программная инженерия сами по себе системами не является. Системная и программная инженерия представляет собой коллекции методов проектирования и эвристик, позволяющих инженерам управлять жизненным циклом систем.
К сожалению, это не моя мысль. Об этом давно сказано архитекторами. У них это звучит так:
Архитектурная инженерия (зодчество) — это коллекция методов и эвристик, помогающих архитекторам возводить здания.
Вот и живите теперь с этим!
Инженерия — не фантастика!
Отношение науки и инженерии к художественной литературе совершенно разное. Науке неинтересна фантастика, ведь этого ещё нет. А инженерии неинтересна беллетристика, ведь всё это уже существует и там нет проблем.
Казалось бы футуризм должен объединять фантастику и инженерию, но и здесь интересы фантастов и инженеров различны.
Научные фантасты исследуют — что там, в будущем? Они вводят фантастические допущения как научные гипотезы, а затем описывают ситуации и события этой вымышленной среды.
Инженеры прогнозируют и предвидят — как там, в будущем? Они анализируют ситуации внешнего окружения, выявляют и оценивают риски — вероятность появления инженерных проблем у организации.
Произведения научной фантастики не применяют непосредственно в инженерии. Однако подобные произведения хорошо подходят для тренировки инженерного мышления, выработки и накопления опыта анализа и оценки ситуации. Подробнее о возможностях фантастики для повышения квалификации инженеров можно прочитать в моей статье «Инженерная фантастика».
Например, анализ ситуаций, приведённых в произведении фантастики позволяет:
Выявить, существует ли в данной ситуации инженерная проблема? А если существует, то:
В какой области практики?
Кто пользователь техники? В чём трудность пользователя?
Определить проблемную область. В какой области деятельности людей возникла инженерная проблема?
Определить границы проблемного пространства. В каком инженерном объекте возникла проблема?
Выделить проблемные состояния инженерного объекта. В каких свойствах инженерного объекта и в каких состояниях встречена проблема?
Параметризовать свойства и состояния инженерного объекта. Ввести количественные критерии и граничные значения.
Прогнозировать проблемный риск. Оценить вероятность возникновения инженерной проблемы (инцидента).
Задать триггеры инженерной проблемы. В каких свойствах и в каких состояниях может произойти выход за пределы граничных значений? Что может послужить запуском цепи нежелательных событий?
Выбрать методы проектирования. Какими методами проектирования владеет команда проекта? Какие из доступных методов можно выбрать для решения инженерной проблемы?
Сформулировать цель решения инженерной проблемы. Какое действие пользователя по преодолению трудности следует назвать успехом?
Надеюсь вышеприведённый пример поможет вашей команде составить план и вопросник для собственного тренинга фантастической инженерии.
Заключение
Вот так шло обсуждение темы отличия науки от инженерии в нашем киберклубе. В завершение мы сделали для себя следующие выводы.
Инженерия — это особый талант (способность разума) людей, который применяют для проектирования и обслуживания техники.
Инженерия не даётся от рождения. Это умения, которые формирует практика. Чтобы стать инженером нужно делать технику, а не читать о ней. Инженерия — не наука!
Накопление инженерного опыта позволяет выделить этапы становления инженера:
Новичок. Независимо от ситуации строго соблюдает правила, высказанные другими инженерами.
Продвинутый новичок. Размышляет как сторонний наблюдатель. Занят различением ситуаций, глубоко анализирует контекст ситуации. Относит ситуацию к существующему классу ситуаций и далее следует максимам этого класса.
Компетентный инженер. Размышляет как сторонний наблюдатель. Не проводит обширного и всеобъемлющего сбора сведений о ситуации. Не делает попыток учесть анализировать все доступные данные. Вместо этого определяет перспективу, ставит цели, отделяет значимое от всего, что можно безопасно игнорировать.
Опытный инженер. Не размышляет о ситуации с точки зрения стороннего наблюдателя, а погружает себя в ситуацию. Видит трудности изнутри, а не снаружи. Он не генерирует варианты и не выбирает альтернативы. Видит и понимает что и как нужно делать.
Эксперт. Воспринимает ситуацию через себя как отдельный экземпляр определённого класса ситуаций. Видит и понимает что и как нужно делать. Понимает тонкие различия в контексте каждой отдельной ситуации. При возникновении новой, незнакомой эксперту ситуации, он быстро проходит все стадии приобретения навыка: от новичка до эксперта. Он умеет это делать быстро и точно: общие правила, максимы, различение ситуаций, эвристики и интуитивный опыт.
Замечательно то, что на каждом последующем уровне инженерии всё меньше рационального и всё больше интуиции и эвристики. Оказалось, что компетентность инженера это умение концентрировать внимание на том, что действительно нужно и важно и быстрого перехода к ликвидации трудности. Компетентность это нечто большее, чем (научные) знания. Это высокая вероятность нахождения нужного решения в нужное время для нужной ситуации. Инженерное суждение невозможно отнести ни к произвольным, ни к алгоритмическим. На инженерное суждение не влияют ссылки на авторитеты и мнения коллег.
Квалифицированный инженер не решает проблем и не занят пространными объяснениями. Вместо этого он быстро делает так, чтобы всё работало на достижение успеха.
Инженерия ни наука, ни технология, ни система и ни фантастика. Инженерия — это инженерия!
Библиография
Предыдущие статьи о киберклубе научной фантастики и проведённых «мозговых штурмах».
Киберклуб научной фантастики. О стихийном появлении клуба внутри инженерной организации.
Хронология зарубежной научной фантастики. Хронологический справочник зарубежной научной фантастики. Хронология охватывает период со 160 года до 1 января 2025 года. Создан для анализа идей фантастических инженерных решений.
Инженерная фантастика. Поиск связи научной фантастики с программной инженерией.
Инженерная фантастика. Попытка обосновать методы для инженерных тренингов с помощью научной фантастики.
Такие разные обзоры. Обоснование методов анализа научной фантастики и классификация видов обзоров, применяемых для оформления выводов анализа. Описана общая структура обзора. Показан синкретизм обзоров, позволяющий конструировать сочетание методов и обзоров.
Киберпространство: генезис. Обзор вклада фантастов и инженеров в техническое воплощение киберпространства.
Научная фантастика в NASA. Обзор использования научной фантастики в Европейском космическом агентстве.
Научная фантастика в ЕКА. Обзор использования научной фантастики в Европейском космическом агентстве.
Метафоры киберпространства в фантастике. Описан метод метафор для восприятия образа неизвестной области деятельности и совершенно незнакомого инженерного объекта.
Ссылки
1. Берков В. Ф. Научная проблема (логико-методологический аспект). Минск, 1979.
2. ISO/IEC/IEEE 15288:2023, 3.26. ISO/IEC/IEEE 12207:2017, 3.1.32.
3. ISO/IEC/IEEE 12207:2017, 3.1.52. ISO/IEC 29110-1-2:2024, 3.95. ISO/IEC TR 19759:2016, Software Engineering. — Guide to the Software Engineering Body of Knowledge (SWEBOK). ISO/IEC/IEEE 24765:2017, 3.3810.
