ТРИЗ+ как специализация некоторых практик системной инженерии
Краем бока в дискуссии https://www.facebook.com/alexey.fomenko.188/posts/1937942933093646?comment_id=1938297843058155&comment_tracking=%7B%22tn%22%3A%22R2%22%7D зацепили и связь ТРИЗ и системной инженерии -- кем они приходятся друг другу, могут ли ужиться в одном проекте.
-- Domain ТРИЗ это одна из специализаций части (но не всех) практик системной инженерии: классический ТРИЗ главным образом инженерии системной архитектуры, а ТРИЗ+ включает инженерию требований. Никаких там противоречий с системной инженерией нет и в помине, есть просто некоторые акценты. Часть практик ТРИЗ, конечно, вылезает за пределы системной инженерии, но я бы отнёс это к мыслительному фитнесу: самой способности что-то думать. Развитие творческого воображения, например. А вот всё остальное -- это варианты системноинженерных практик. Системная инженерия не уточняет практики, она просто говорит, что без архитектурной работы каюк, и говорит, что обычно эта работа сводится к совмещению логической и физической архитектур (функциональной и конструктивной структур). И дальше десятки школ учат, как это делать. И ТРИЗ тоже одна из таких школ. Никаких противоречий. При этом системная инженерия просто учитывает, что управление конфигурацией и изменениями тоже должны быть, а в ТРИЗе этого нет. Ну, системный инженер использует практики ТРИЗ+ для инженерии требований, для инженерии системной архитектуры, а вот для управления конфигурацией и изменениями использует какие-то другие практики, например задействует IEC 81346 для именования функциональных элементов, и конструктивных элементов, и мест в компоновках. А для ведения испытаний (V&V) задействует тоже какую-то методологию -- скажем, порождение тестов вместо их ручного составления. И это никак не зацепит использование практик ТРИЗ. Так что не нужно противопоставлений, никто никого не отменяет, есть полная совместимость.
[но в ТРИЗ изобретают новое! там работают с ранее неизвестными инженерными решениями! и ТРИЗ не фитнес-тренировки, а про реальные решения!]
-- Я на эту тему дискутировал с тризовцами уже не раз, поэтому примерно понимаю, какие идут там аргументы. Но системные инженеры регулярно делают first in a kind системы, и изобретают они предостаточно. Это можно делать по какому-то методу, можно "интуитивно" делать. Главное, что есть чёткое место для изобретений: поиск архитектурных решений. Но в системной инженерии для впервые в истории человечества делаемого много и других практик, кроме архитектурной. ТРИЗ+ включает инженерию требований, так что не всё сводится к классическим изобретениям внутри ТРИЗ.
Фитнес -- это не тренировки, это готовность к действию. Или ты умеешь читать, или не умеешь. Понятно, что читать учиться лучше тренировками. Но для занятий инженерией "уметь читать" это фитнес, другой уровень. Равно как иметь развитое воображение для ТРИЗ и для системного инженера нужно уметь. Вот занимаются ли системные инженеры, которые незнакомы с ТРИЗ тренировками воображения и используют ли для этой тренировки какие-то предписанные паттерны -- вот это вопрос.
Это всё стандартные рассуждения по управлению жизненным циклом, рассуждения о практиках. Кусочек методологии в рамках системной инженерии. Но от системных инженеров требуется владеть практикой life cycle modeling и "упаковывать" разных членов команды в рамках одного целостного инженерного проекта. Поэтому рассуждения о кооперации системных инженеров и ТРИЗовцев не являются для системных инженеров необычными, разве что ТРИЗ это не предметная инженерия, а специализация практик системной инженерии, но это без разницы.
Мы провели довольно много заседаний по разбирательству с практиками ТРИЗ в их отношении к практикам системной инженерии (http://ailev.livejournal.com/1231951.html), так что это я не просто так говорю, это результаты специального исследования. Опять же, в системной инженерии более полусотни лет с момента появления ТРИЗ много чего происходило. Нельзя даже сравнивать сегодняшнюю системную инженерию с той не слишком структурированной в части методологических (о практиках и жизненном цикле) рассуждений, которая была лет двадцать назад. Всё сегодня происходит быстро. Если двадцать лет назад жизненный цикл воспринимался, скорее, как проект со стадиями, то сегодня -- как набор практик жизненного цикла. Так что системые инженеры сегодня хорошо подготовлены к разговору о деятельностях, а не только о проектах. Всё-таки 2017 год на дворе.
-- Domain ТРИЗ это одна из специализаций части (но не всех) практик системной инженерии: классический ТРИЗ главным образом инженерии системной архитектуры, а ТРИЗ+ включает инженерию требований. Никаких там противоречий с системной инженерией нет и в помине, есть просто некоторые акценты. Часть практик ТРИЗ, конечно, вылезает за пределы системной инженерии, но я бы отнёс это к мыслительному фитнесу: самой способности что-то думать. Развитие творческого воображения, например. А вот всё остальное -- это варианты системноинженерных практик. Системная инженерия не уточняет практики, она просто говорит, что без архитектурной работы каюк, и говорит, что обычно эта работа сводится к совмещению логической и физической архитектур (функциональной и конструктивной структур). И дальше десятки школ учат, как это делать. И ТРИЗ тоже одна из таких школ. Никаких противоречий. При этом системная инженерия просто учитывает, что управление конфигурацией и изменениями тоже должны быть, а в ТРИЗе этого нет. Ну, системный инженер использует практики ТРИЗ+ для инженерии требований, для инженерии системной архитектуры, а вот для управления конфигурацией и изменениями использует какие-то другие практики, например задействует IEC 81346 для именования функциональных элементов, и конструктивных элементов, и мест в компоновках. А для ведения испытаний (V&V) задействует тоже какую-то методологию -- скажем, порождение тестов вместо их ручного составления. И это никак не зацепит использование практик ТРИЗ. Так что не нужно противопоставлений, никто никого не отменяет, есть полная совместимость.
[но в ТРИЗ изобретают новое! там работают с ранее неизвестными инженерными решениями! и ТРИЗ не фитнес-тренировки, а про реальные решения!]
-- Я на эту тему дискутировал с тризовцами уже не раз, поэтому примерно понимаю, какие идут там аргументы. Но системные инженеры регулярно делают first in a kind системы, и изобретают они предостаточно. Это можно делать по какому-то методу, можно "интуитивно" делать. Главное, что есть чёткое место для изобретений: поиск архитектурных решений. Но в системной инженерии для впервые в истории человечества делаемого много и других практик, кроме архитектурной. ТРИЗ+ включает инженерию требований, так что не всё сводится к классическим изобретениям внутри ТРИЗ.
Фитнес -- это не тренировки, это готовность к действию. Или ты умеешь читать, или не умеешь. Понятно, что читать учиться лучше тренировками. Но для занятий инженерией "уметь читать" это фитнес, другой уровень. Равно как иметь развитое воображение для ТРИЗ и для системного инженера нужно уметь. Вот занимаются ли системные инженеры, которые незнакомы с ТРИЗ тренировками воображения и используют ли для этой тренировки какие-то предписанные паттерны -- вот это вопрос.
Это всё стандартные рассуждения по управлению жизненным циклом, рассуждения о практиках. Кусочек методологии в рамках системной инженерии. Но от системных инженеров требуется владеть практикой life cycle modeling и "упаковывать" разных членов команды в рамках одного целостного инженерного проекта. Поэтому рассуждения о кооперации системных инженеров и ТРИЗовцев не являются для системных инженеров необычными, разве что ТРИЗ это не предметная инженерия, а специализация практик системной инженерии, но это без разницы.
Мы провели довольно много заседаний по разбирательству с практиками ТРИЗ в их отношении к практикам системной инженерии (http://ailev.livejournal.com/1231951.html), так что это я не просто так говорю, это результаты специального исследования. Опять же, в системной инженерии более полусотни лет с момента появления ТРИЗ много чего происходило. Нельзя даже сравнивать сегодняшнюю системную инженерию с той не слишком структурированной в части методологических (о практиках и жизненном цикле) рассуждений, которая была лет двадцать назад. Всё сегодня происходит быстро. Если двадцать лет назад жизненный цикл воспринимался, скорее, как проект со стадиями, то сегодня -- как набор практик жизненного цикла. Так что системые инженеры сегодня хорошо подготовлены к разговору о деятельностях, а не только о проектах. Всё-таки 2017 год на дворе.