Обсуждение

Спасибо, впечатлён. Не архитектор.

Логика присутствует, но она тут теоретически бессильна: из того, что все составляющие бинарного газа безопасны вовсе не значит, что сам бинарный газ как система будет безопасен. Вообще-то логика - это единственный, точнее неизбежный вариант :). Ибо тестировании не способно гарантировать качество, нужна автоматизация - а она опирается на логики. Ну а поскольку сейчас практически любая система опирается на софт - то мимо логик не пройти. Да, пока это дорого, но эта дороговизна относительна, вручную тот же уровень качества достигается с гораздо более существенными затратами.

Это касается и "ностей". "Ность" обеспечивается совокупностью физических, технических и административных компонентов, но моделирование их, особенно взаимодействия, в промышленном масштабе так или иначе требует логик.

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

:-) Тем не менее... там где пытаются создавать системы требуются именно системные АНАЛИТИКИ. Еще закономерен вопрос - чем занимается основная масса производителей систем (имея в виду "программные" системы)? По этому поводу вспоминается старая шутка - каждый программист всю свою жизнь пишет и совершенствует единственную программу (систему). В новой редакции после листания разнообразия всяческих фреймворков эту шутку следует переиначить - сейчас все разработчики всю свою жизнь пишут и совершенствуют единственную систему.

Эта логика уже про другое. Логика нужна, но на своем месте.

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

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

Анатолий, непонятно. Есть система, есть ее составные части. Есть требования к системе и составным частям. Вредно разносить разнесенные требования к разнесенным частям или как? Путаница некая возникает. Что значит, практически нетрассируемы?

Для синтеза нужен предварительный анализ. А модели очень хороши для понимания требований (даже если из них нагенерить ничего работоспособного не получилось). А если есть детальное понимание требований - т.е. они интериоризировались архитектором - то можно уже и синтез вести.

Попробуйте с нейросетями поковыряться. Хороший способ прочувствовать - о чем идет речь.

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

нейросети есть, кажется,в асу тп. Надо поспрошать, спасибо.

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

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

Мы не сущее тут обсуждаем, а дОлжное (и не путать с должностнЫм ;)

Ну вот, наконец-то, мы и дошли до тупика.

Вроде, из этого тупика никуда и не выходили. Я просто привлекаю внимание к важному моменту. Любое продвижение вперед должно быть только в этом месте, любые новшества нужно искать в этом месте. А "разноска" и "матрицы" -- нужно тщательно смотреть, не пустопорожнее ли это занятие. А что, можно было подумать, что я про что-то другое тут писал?! Или призывал заниматься дурной бессистемной (внесистемной) работой?

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

Ну, я тут просто говорю, что есть разные понятия трассировок -- и некоторые из них так просто вредные, и вопрос даже не в ресурсах. И показываю, где именно тут собака порылась. Дело не в отходе от тех или иных стандартов. Дело в том, что в стандартах (особенно больших и сложных, типа ISO 15926) есть множество правильных и неправильных идей. И нужно точно знать, где "голосованием" протащили идею неправильную. Вот идея разноски-трассировки тут не из системного подхода, поэтому будет отрабатываться неверно. А вот идея quality case -- из другого подхода, который учитывает системность и невозможность прямого соотнесения требований с ilities к "проектным решениям" разного уровня. Но там совсем другой принцип организации сведений о принятых проектных решениях, другая структура, нежели тупая "трассировка требований" -- как раз учитывается этот непрямой характер и дается форма для его выражения. Но в супербольших проектах при неминуемо большом бюджете приходится проверять и перепроверять, и вся фишка в том, чтобы организовать проверку в том случае, когда она теоретически, вроде, невозможна. Прорваться с уровня проверки требований к клеткам олимпийского чемпиона на уровень проверки того, "пробежит ли дистанцию марафона" -- возможно, обнаружив, что в клетках должна быть какая-то особая биохимия. Но эта "биохимия"-то не сможет быть "оттрассирована" простым образом! Требуются специальные средства для ее выражения.