OberonCore

В приложенном файле дано описание предприятия, как системы. При моделировании предприятия не использовалось ничего такого, что выходило бы... за определение системы.

О том, чего нет в приложенном файле:
1. Подробного описания макро-уровня (это отдельная большая и интересная тема);
2. Описания подсистем (достаточно большая тема, но если появится интерес, то ее можно обсудить здесь).

PS. Благодарю за проявленный интерес к теме.

Хотя раньше по "Королевству" был знаком уже с Вашим подходом, прочел ещё раз с большим интересом...

Но вот как быть с информационным предприятием? Которое что-то проектирует?
Это проходит по типу промышленных предприятий, так? Потому что цикл переработки есть, а не просто перераспределения?
Какие там нюансы Вы бы отметили?

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

Честно говоря, я не проникся, возможно потому, что ожидал большего.
А в чем Вы видете строгость приведенного текста?
Эта фраза мне вообще непонятна. Так полезен или нет описательный подход? И какой подход использован в приведенном тексте?
Если бы Вы привели еще пример правильной верификации какого-нибудь бизнес-процесса, возможно, многие вопросы бы отпали.
Графический язык, который использован в тексте, допустим, нагляден, но он не стандартизован. Это даже не язык, а набор рисунков.

Могу выразить сочувствие...
В том, что... охвачены все возможные преобразования ресурсов, значит определены все возможные функциональные типы подсистем, ну, и, следовательно, любое предприятие можно моделировать этим простым набором.
Ну, что я могу Вам сказать...
К сожалению, мне неизвестны методы верификации бизнеспроцессов, ни тех, что рисуют в IDEF, ни тех, что рисуют в ARIS... Это что-то вроде свободного творчества... нечто вроде современного авангардизма...
Это именно набор рисунков... качество, конечно, не очень... не художник я...

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

Уточню - искусственной системы. Кстати, есть иные мнения по смыслу критерия эффективности искусственных систем - см. у Орлова в Гл.14 работы, выдержка из которой вложена в это сообщение.

Хм?.. Если бы люди понимали законы (экономического) развития и, строили свою деятельность, исходя из этого понимания, то... может быть... я бы и согласился с подобным уточнением...
Бросьте Вы этот ТРИЗ... мой Вам (добрый) совет... Все попытки "разъять Гармонию алгеброй"... бесподны...

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

Я воспринимал ТРИЗ точно так же, при поверхностном знакомстве.

Почитал книгу новую Орлова "Основы классической ТРИЗ" - понравилось. Увидел, что речь не о "разъятии алгеброй гармонии", а просто об организации, ну.. "виртуального рабочего места" для решения задач. Упорядочивание рутинной, "количественной" части штурма проблемы (на основе систематизации средствами диалектики), чтобы быстрее подойти к сути проблемы и уже решить её, как принято "озарением". Типа того.

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

Начали за здравие, со строгой формализацией.
А кончили за упокой.

Почему же... за упокой?.. Помимо Сальери был еще и Моцарт... К открытиям ведет совсем иной путь. Формализация полезна не до... а после того, как открытие свершилось. Формализация, сделанная до открытия, - это формализация гипотезы. Смысла в этом нет (важно прямое прочтение этой фразы!).

Вся проблема в том, что моцартов не хватает...

... это тоже не факт. Думается мне, что "Моцартов" в нынешние времена ничуть не меньше, чем в прошлые...
Не думаю, что современное общество готово к принятию "Моцартов"... ему по нраву "кабацкая музыка". Ныне бал празднуют "Сальери" и "содержатели кабака"... конечно...

К озарению - не ведут. Но мышление - раскрепощают. Озарения нужны редко. Очень часто для решения технической проблемы хватает простого морфологического синтеза.

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

О синтезе и верификации деятельности

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

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

А я, между, прочим в отношении ТРИЗ согласен с обоими утверждениями - потому что какого-либо противопоставления здесь не вижу. В "классической" ТРИЗ (по ранним представлениям Альтшуллера), по-видимому, внешне непротиворечиво получалось, что формальным методом можно прийти и к открытию - но у Орлова уже этого нет, а есть то, о чём говорит Илья. Теории определено назначение в соответствии с её названием - для обеспечения изобретательства - и показано, что "это работает". В то же время и к Орлову у меня возникли некоторые вопросы - см. пункт 2) в этом сообщении. Любопытно будет и Ваше мнение...

Но самое интересное - что упомянутая мной вещь, послужившая точком к этой дискуссии, вообще к ТРИЗ не относилась - просто она опубликована в этой книге См. следующее сообщение.