Эффективный алгоритм для изобретательского софта

IV конференция  "ТРИЗ. Практика применения методических инструментов"

Эффективный алгоритм для изобретательского софта

Николай Шпаковский, мастер ТРИЗ, Елена Новицкая, 3й уровень ТРИЗ

 

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

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

Большая часть софтверных продуктов на базе ТРИЗ устроена модульно. Один модуль = один ТРИЗ-инструмент. Это закономерное явление, поскольку отдельные ТРИЗ инструменты прекрасно перекладываются на софтверный язык. Что может быть проще, чем запрограммировать таблицу разрешения технических противоречий? Разве что – запрограммировать инструменты вроде многоэкранной схемы и оператора РВС. Система стандартов – тоже сравнительно легко алгоритмизируема [1], хотя это потребует больше труда.

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

Работа с задачей требует последовательного применения разнообразных ТРИЗ инструментов. Для полноценной работы нужен алгоритм для всего процесса решения, указывающий, когда и для чего применять каждый инструмент. То есть отдельные ТРИЗ инструменты (и, соответственно софтверные модули) должны быть встроены в некоторую единую логическую структуру.

На первый взгляд, такой структурой является АРИЗ 85Б. Однако попытки построить софт, строго следуя логике АРИЗ, стопорятся рядом его особенностей. Среди них следующие:

  1. Далеко не все классические инструменты ТРИЗ нашли своё место в АРИЗ 85Б. Тем более остаются за его рамками новые, эффективные инструменты, поскольку они появились позже создания классической версия АРИЗ 1985 года.
  2. В АРИЗ-85 есть нарушения логики [2, 3].
  3. Весьма отличается степень детализации шагов. Одни аспекты проработаны тщательно, другие даны в виде общих рекомендаций.
  4. Язык и методические подходы АРИЗ крайне специфичны. Работать с ним может только хорошо образованный в ТРИЗ решатель, что специально оговаривается в предисловии к данному алгоритму [4]. То есть обычный пользователь не сможет эффективно пользоваться АРИЗ-софтом, а адаптация софта под такого пользователя неизбежно повлечёт за собой значительную переделку алгоритма.

Есть ещё одна важная особенность АРИЗ 85Б, которая не влияет на переложение его в софтверную форму, однако ограничивает его применение для всех этапов решательного процесса. Это отсутствие блока анализа проблемной ситуации для выделения конкретных задач. Предполагается, что к моменту начала работы с АРИЗ задачи уже сформулированы. Однако это огромный кусок работы, где решателю тоже требуется методическая поддержка.

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

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

 

2. Требования к алгоритму для изобретательского софта

Каким требованиям должен соответствовать алгоритм, подходящий для софтверного продукта на базе ТРИЗ? Такой алгоритм должен:

  • быть специализированным: «заточенным» исключительно под решение задач по устранению недостатков. Действительно эффективный и детализированный алгоритм не может быть универсальным (например, одинаково подходить для задач по устранению недостатков и для прогнозных задач) [5].
  • методически поддерживать весь процесс решения: от уточнения проблемной ситуации до полного устранения недостатка и анализа улучшенной ситуации.
  • быть полностью логичным, без каких-то неточностей, неясностей и противоречий.
  • иметь одинаковую степень детализации на всех своих шагах.
  • быть по возможности простым, но без потери решательных свойств, то есть иметь оптимальный уровень сложности.

Такой алгоритм под названием АИПС (Рис. 1) был разработан и многократно проверен в производственных проектах [6]. На его основе разработан софтверный продукт Solving Mill.

Алгоритм создавался на базе всего методического корпуса ТРИЗ, включая отдельные инструменты, АРИЗ, теоретические положения.

Рис. 1. Алгоритм исправления проблемных ситуаций (АИПС, версия 2012) и его графическая схема.

 

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

Остановимся на двух «узких местах» процесса работы с задачей по методике ТРИЗ, которые потребовали тщательной проработки. Первый – это собственно выделение конкретной технической задачи из исходной проблемной ситуации. Второй – получение конкретного технического решения, подходящего для реальных производственных обстоятельств.

 

3. Выделение технической задачи из проблемной ситуации

Правильное формулирование технической задачи – ключевой момент работы решателя. В АРИЗ 85Б этот важный момент полностью отсутствует, считается, что работу по АРИЗ мы начинаем, уже имея сформулированную задачу. Классическая ТРИЗ не даёт чётких инструментов выделения  и формулирования задач. Естественно, что этот важный момент не мог остаться за пределами внимания ТРИЗ-практиков.

А.М. Пиняев [7] предлагает переходить к изобретательской задаче посредством функционального анализа изобретательской ситуации и причинно-следственного анализа нежелательных эффектов с выявлением ключевых из них.

В версии АРИЗ Кишинёвской школы ТРИЗ (АРИЗ-СМБА-91) [8] также предлагается формулировать задачи путём функционального анализа изобретательской ситуации и выявления вредных функций, которые требуется устранить.

Методы GEN3 предлагают ещё более широкий угол зрения на ситуацию [9], чтобы выбрать для улучшения перспективную техническую систему  и не тратить время и силы на работу с малоперспективной.

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

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

Чаяниям нашего инженера лучше всего отвечает алгоритм АВИЗ (авторы Г. Иванов и А. Быстрицкий). Согласно АВИЗ нужно провести анализ ресурсов, которые непосредственно связаны с «нежелательным элементом», провоцирующим «нежелательное событие». Далее, используя формулировку ИКР, ставятся задачи о возможности применения выбранных ресурсов [10]. Заметим, что здесь нет распыления внимания решателя на множество недостатков, работа идёт с одним определённым недостатком.

Наш подход близок к подходу Иванова и Быстрицкого – мы также предлагаем искать способы устранения недостатка по нескольким направления, формулируя для этого «веер» задач. Отличие заключается в самом способе выделения задачи, поскольку используется вспомогательный шаг – формулирование гипотез о способах устранения конфликта.

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

Гипотеза – это предположение о том, при каких условиях можно устранить конфликт. То есть – что нужно сделать для устранения конфликта.

Однако реализации предложенных способов могут препятствовать разнообразные ограничения, или она может приводить к появлению новых недостатков. Также может быть просто неизвестно, как технически реализовать данный способ. Таким образом, выкристаллизовывается конкретная техническая задача: как добиться цели, обойдя ограничения, избежав появления новых недостатков и т.п. Задача имеет формулировку – как сделать то, что предложено в гипотезе.

Если же никаких новых недостатков и ограничений нет, а способ технической реализации очевиден, то гипотеза автоматически превращается в решение.

Какую пользу дают гипотезы о способах устранения конфликта?

  • Они позволяют увидеть всё поле возможных решений и не упустить важных направлений поиска.
  • Благодаря такой полной картине легко выбрать перспективные направления работы.
  • В гипотезе уже может содержаться устраивающее решение, и тогда отпадает необходимость в дополнительных трудозатратах.

При поиске подходящих инструментов выяснилось, что многие инструменты, используемые в ТРИЗ для других целей, могут быть адаптированы для выдвижения гипотез.

Наиболее простые – оператор РВС и 9-экранка. Они позволяют взглянуть на ситуацию широко и раскачать инерцию мышления. «Вредная система» [11] и причинно-следственный анализ – более точно нацеленные инструменты. Разные способы поломки выявленной вредной системы, провоцирующей недостаток, – прекрасный источник гипотез. Аналогично можно попытаться разорвать причинно-следственную связь негативных событий, приводящих к появлению недостатка. Ещё один инструмент – улучшение компонентов полезной системы. Каждый из этих инструментов легко формализуется. Инструкция по работе с инструментом может быть сформулирована в виде простого мини-алгоритма из нескольких шагов. И, закономерно, такой алгоритм можно реализовать программными средствами – в виде так называемого оператора.

Порядок действий в софте следующий. Пользователь формулирует гипотезы – произвольно или пользуясь одним из пяти операторов (Рис. 2).

Рис. 2. Оператор для выдвижения гипотез о способах устранения конфликта

путём поломки вредной системы.

 

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

Рис. 3. Шаблоны для формулирования гипотез и задач.

 

4. Переход от принципиальной идеи к техническому решению

В ТРИЗ есть множество методов по получению принципиального решения задачи: изобретательские приёмы, система стандартов, ММЧ, линии развития, ресурсы, оператор РВС и прочее. Ключевое слово здесь – принципиальное решение. Инструменты ТРИЗ способны только подтолкнуть решателя к некоторой идее, дать полезную подсказку, но пройти остаток пути к конкретному техническому решению он должен сам.

Все известные нам алгоритмы строятся по такому способу: «примени <инструмент>, запиши идею». Слишком большая лакуна между применением инструмента и идеей, то есть – техническим решением. Мы сочли необходимым заполнить эту лакуну (напомним, что одно  из требований к алгоритму – равномерность детализации).

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

Первый шаг хорошо проработан в ТРИЗ и легко поддаётся формализации. Выше мы уже говорили о том, что инструменты ТРИЗ переведены на язык софта многими разработчиками.

С требованиями к ресурсу ситуация несколько сложнее. Набор этих требований может быть чрезвычайно разнообразным. Простейший вариант – позволить решателю записать эти требования в произвольной форме. Но тогда мы не сможем эффективно использовать список требований для поиска ресурса.

Мы попытались структурировать требования. Что такое список требований к ресурсу? Собственно, это его описание, своеобразный словесный портрет. Проведём аналогию с составлением фоторобота. Есть ряд значимых атрибутов, по которым можно провести классификацию – форма лица, высота лба, расстояние между глазами и т.п. Правда, ресурсы для решения изобретательских задач гораздо более разнообразны, чем человеческие лица, что угодно может оказаться подходящим ресурсом: вещество, поле, устройство. Но, тем не менее, можно выделить ряд атрибутов, которыми с большой вероятностью обладают обширные классы ресурсов. Например, для вещественных ресурсов это будут: размер, количество, свойства материала, химические свойства, свойства поверхности и т.д.

В ходе проверки атрибутного описания ресурса на семинарах и в практической работе выяснилось, что полезнее делить описание на две части – отдельно описывать атрибуты действия, которое необходимо для устранения конфликта, и отдельно – сам ресурс-исполнитель действия. Среди атрибутов действия такие: тип действия (например, нагревать, ударять, тормозить, разделять), интенсивность, постоянство/периодичность, размеры области действия и т.д.

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

Если ресурс подходит, то программа предлагает пользователю заготовку решения, которую остаётся уточнить и конкретизировать – то есть сформулировать собственно техническое решение.

Рис. 4. Оператор для конструирования технического решения.

 

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

 

Выводы

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

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

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

 

Литература

1. Рубин М., Алгоритм использования стандартов на решение изобретательских задач (Aист-77), 2010, www.temm.ru.

2. Петров В., Рубин М., Требования к разработке АРИЗ нового поколения, 2009, ТРИЗ Саммит 2009.

3. Каган Э., Мое видение недостатков АРИЗ-85В, 2009, Материалы ТРИЗ Саммита 2009.

4. Альтшуллер Г., Алгоритм решения изобретательских задач, 1985, www.altshuller.ru.

5. Иванов Г., Обращение к разработчикам алгоритма, 2009, Материалы ТРИЗ Саммита 2009.

6. Шпаковский Н., Новицкая Е., ТРИЗ. Практика целевого изобретательства, М., Форум, 2011.

7. Пиняев А. М. «Применение причинно-следственного анализа для постановки изобретательских задач» (Functional Why-Why Analysis), 2007, 2009, Материалы ТРИЗ Саммита 2007.

8. Зусман А., Злотин Б., АРИЗ-СМВА-91, 1991, Кишинёв

9. Литвин С., Инструменты Определения “Правильных Задач” в Методике G3 : ID, 2007, ТРИЗ Саммит 2007.

10. Иванов Г., Быстрицкий А., Мини алгоритм выбора инженерных задач из производственно-технологической проблемной ситуации - АВИЗ 2005, 2005, Материалы МАТРИЗ Fest 2005.

11. Леняшин В., Ким Х., Вредная система. Использование этого понятия в современной ТРИЗ, 2006, www.metodolog.ru/00859/00859.html.

 

 

Алфавитный указатель: 

Рубрики: 

Комментарии

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Захаров Павел.

Цитата:

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

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

 

P.S. Про программу USESoft (автор и разработчик - Захаров Алексей Николаевич) авторы не слышали?

Положенный в ее основу алгоритм, носящий название "Универсальная Схема Эволюции" - эффективный, детализированный и универсальный. 

Re: Эффективный алгоритм для изобретательского софта

По-моему, здесь "оба правы". Говорю это как автор некоего достаточно универсального метода, объединившего возможности полусотни ранее известных методов и дополнительно "умеющего" много чего еще. Такие методы возможны, если разрешить противоречие "метод должен быть минимально детализированным, чтобы быть универсальным, и метод должен быть максимально детализированным, чтобы быть точным/эффективным".

Но... почему же метод USESoft до сих пор никем не примеряется, кроме автора(-ов)? Ведь универсальный и точный метод, объединяющий прогнозирование и решение любых инновационных задач, наверняка был бы востребован многими... Что им мешает? Наверное, метод все же не настолько замечателен, как кажется его авторам. Но в принципе универсальный (по сравнению с существующими) метод создать наверняка можно. У каждого свой путь - кто-то давит на универсальность, кто-то на эффективность, кто-то на простоту и т.д. И все правы...

Re: Эффективный алгоритм для изобретательского софта

Захаров Павел wrote:
Про программу USESoft (автор и разработчик - Захаров Алексей Николаевич) авторы не слышали?

Положенный в ее основу алгоритм, носящий название "Универсальная Схема Эволюции" - эффективный, детализированный и универсальный.

У авторов есть такой сильный козырь - их инструмент реально применяется на предприятии уже длительное время. На корейском металлургическом гиганте "Posco". Не сам по себе применяется, а Николай Шпаковский из года в год его применяет, решая задачи и заодно прививая как культуру мышления в процессе обучения инженеров предприятия.

Не берусь ничего советовать, но это явно один из путей к признанию и на рынок.

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

Захаров Павел wrote:
Про программу USESoft (автор и разработчик - Захаров Алексей Николаевич) авторы не слышали?

Положенный в ее основу алгоритм, носящий название "Универсальная Схема Эволюции" - эффективный, детализированный и универсальный.

У авторов есть такой сильный козырь - их инструмент реально применяется на предприятии уже длительное время. На корейском металлургическом гиганте "Posco". Не сам по себе применяется, а Николай Шпаковский из года в год его применяет, решая задачи и заодно прививая как культуру мышления в процессе обучения инженеров предприятия.

Не берусь ничего советовать, но это явно один из путей к признанию и на рынок.

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

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:

priven wrote:

Но в принципе универсальный (по сравнению с существующими) метод создать наверняка можно

Предел универсальности - банальность.

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

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

В споре остроконечников (разработчиков специальных методов) с тупоконечниками (разработчиками универсальных методов) я склонен не присуждать заранее кому-либо победу...

P.S. Единственное, но важное дополнение из личного опыта: до тех пор, пока мой универсальный метод не заработал на практике, никто из окружающих не верил, что его разработка с заявленными параметрами (а я основные параметры метода примерно указал заранее) вообще возможна. Думаю, здесь примерно тот же случай. Авторам универсальных методов могу только посоветовать не показывать кое-кому пол-работы, а показывать ее всю сразу, когда она будет уже полностью сделана.

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:

Ваш чудесный метод-то тут при чём?:)

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

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

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:

И как весь этот "поток сознания" противоречит тому, что "предел универсальности - банальность"?:)

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

Я не понимаю, почему стремление к универсальности НЕИЗБЕЖНО должно вести к потере детализации, или к потере эффективности, или к банальности, и т.д. В моем представлении, это не более чем психологическая инерция: в прошлом опыте было так, значит, так же всегда будет и в будущем. Я не против специализации или универсализации - я против абсолютизации любого из этих "векторов развития" в качестве единственно правильного или единственно возможного.

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

Re: Эффективный алгоритм для изобретательского софта

priven wrote:

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

Интересно, как можно считать универсальным метод, имеющий аналоги в смежных областях?

Или он универсальный в узкой области?

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

priven wrote:

Gregory Frenklach wrote:

И как весь этот "поток сознания" противоречит тому, что "предел универсальности - банальность"?:)

Я и не говорю, что "противоречит",

Вот и хорошо. А всё остальное оставьте для митингов.

Это при том, что я с категоричностью авторов статьи  не согласен.

Каким требованиям должен соответствовать алгоритм, подходящий для софтверного продукта на базе ТРИЗ? Такой алгоритм должен:

быть специализированным: «заточенным» исключительно под решение задач по устранению недостатков. Действительно эффективный и детализированный алгоритм не может быть универсальным (например, одинаково подходить для задач по устранению недостатков и для прогнозных задач) [5].
методически поддерживать весь процесс решения: от уточнения проблемной ситуации до полного устранения недостатка и анализа улучшенной ситуации.
быть полностью логичным, без каких-то неточностей, неясностей и противоречий.
иметь одинаковую степень детализации на всех своих шагах.

Re: Эффективный алгоритм для изобретательского софта

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

Потому что без этого будут банальности.

А самый универсальный инструмент, из тех которые я знаю, это прием №13 из списка Г.С.Альтшуллера: "Сделать наоборот".

 

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

priven wrote:

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

Интересно, как можно считать универсальным метод, имеющий аналоги в смежных областях?

Или он универсальный в узкой области?

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

Насколько я знаю, методы ТРИЗ тоже работают в весьма узкой области - они дают инженеру-конструктору (в меньшей мере - технологу, в еще меньшей - химику-технологу и т.д.) подсказки для поиска решений в проблемных ситуациях. Но расчет балки с помощью этих методов не сделать, свойства стекол по составу даже в очень узкой области не рассчитать, компьютерную программу не отладить и базу данных не садминистрировать. Метод ФСА вряд ли может быть использован для улучшения структуры полимера, а супер-пупер-универсальный USESoft - для прогнозирования общих тенденций изменения составов и свойств халькогенидных стекол.

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

... Как известно, есть девушки, которые не продаются ни за какие деньги, - но они просто очень дорого стоят. Так же и с универсальными методами...

Re: Эффективный алгоритм для изобретательского софта

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

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

Полностью согласен с тем, что ТРИЗ дает подсказки для решения в проблемных ситуациях, а вовсе не расчет конструкции.

Если взять ситуацию с ТРИЗ за аналог, то метод расчета свойств оксидных стекол станет универсальным, когда он превратится в метод расчета свойств материалов. 

А делать универсальный метод изобретательства для стекол мы действительно пока не научились, хотя Половинкин пошел именно таким путем и его ребята защитили немало диссертаций на методы изобретательства для рессор тепловозов, систем сцепления тепловозов, тормозных муфт тепловозов и пр. 

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

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

Потому что без этого будут банальности.

Александр Владимирович, я готов согласиться с Вами – при определенных условиях и/или ограничениях, которые, быть может, представляются Вам «самоочевидными» или «неизбежными», но едва ли таковыми являются. Например, при условии, что нужно «учить людей транслировать эту общую картинку на реальность» - почему этому вообще нужно учить людей? Почему эту трансляцию нельзя поручить компьютеру?

Почему вообще речь идет об общности именно рекомендаций, а не областью ситуаций, в которых он может быть применен? Потому что одно с другим взаимосвязано? А как насчет устранения противоречия между общностью ситуаций и детальностью рекомендаций? Инструменты ТРИЗ для этого применять не пробовали? Или решение таких задач - за границами их применимости?..

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

Если взять ситуацию с ТРИЗ за аналог, то метод расчета свойств оксидных стекол станет универсальным, когда он превратится в метод расчета свойств материалов. 

А почему так слабо - всего лишь "расчет свойтв материалов"??? Почему бы не рассчитывать заодно и свойтва любых объектов, состоящих из любых материалов? А почему бы не рассчитывать еще и потребительские свойства любого продукта, в состав которого входят любые объекты, состоящие из любых материалов?

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

Ладно, ограничимся только свойствами материалов. А что по оси абсцисс учитывать будем? Хим. состав? Атомную структуру? Кристаллическую структуру (а если ее нет)? Технологию? Температуру? Давление? Состав атмосферы? Параметры порядка (какие из ста миллионов возможных)?

Быть может, стОит все-таки немного подумать и о том, чтобы определить границы применимости методов? В том числе - о ужас, снова еретическую мысль скажу, - даже и всемогущих методов ТРИЗ...

Re: Эффективный алгоритм для изобретательского софта

priven wrote:
А почему так слабо - всего лишь "расчет свойтв материалов"???
Потому что это по уровню общности похоже на требования к методам решения изобретательских задач. Пусть не тождественно, но похоже.

А какие там оси нужны - решать тому, кто его сделает. 

И подсказка есть, простая и универсальная  - делать надо "наоборот". то есть не так, как делали раньше, когда не получалось.

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

И подсказка есть, простая и универсальная  - делать надо "наоборот". то есть не так, как делали раньше, когда не получалось.

Полностью солидарен! Мой любимый прием, испробованный десятки, если не сотни раз, в реальных проектах самой разной тематики. "Послушай женщину и сделай наоборот" (с)

Что касается "расчета свойств материалов" - здесь не уверен: в моем представлении, эта задача будет посложнее, чем задача создания единого и универсального метода ТРИЗ. Могу, естественно, ошибаться.

Re: Эффективный алгоритм для изобретательского софта

Что касается "расчета свойств материалов" - здесь не уверен: в моем представлении, эта задача будет посложнее, чем задача создания единого и универсального метода ТРИЗ.

Это понятно. У каждого своя кошка.

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

Что касается "расчета свойств материалов" - здесь не уверен: в моем представлении, эта задача будет посложнее, чем задача создания единого и универсального метода ТРИЗ.

Это понятно. У каждого своя кошка.

Не совсем. Просто сравните число людей, которые занимались и занимаются разработкой новых методов расчета свойств материалов, с числом людей, которые занимались и занимаются разработкой методов ТРИЗ. Не кажется ли Вам, что это не вполне сравнимые множества?

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Предел универсальности ТРИЗ на уровне банальности -измени что-нибудь, чтобы улучшить. Чуть-чуть отодвинемся от предела - надо опрделиться с тем, что изменять, для чего, как, когда и где. Ну и т.д.:)

Re: Эффективный алгоритм для изобретательского софта

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

Если чем-то занимается мало людей, то видимо это потому, что задача легкая? Тогда квантовая теория гравитации попроще будет, чем придумывание новых причесок.

На эту тему придумал задачку (спасибо за наводку).

Одна группа людей числом 10 человек не может поднять камень №1

Вторая группа людей числом 20 человек не может поднять камень №2

Какой камень тяжелее?

Буду использовать при отборе в группы.

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

На эту тему придумал задачку (спасибо за наводку).

Одна группа людей числом 10 человек не может поднять камень №1

Вторая группа людей числом 20 человек не может поднять камень №2

Какой камень тяжелее?

Буду использовать при отборе в группы.

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

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

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

Re: Эффективный алгоритм для изобретательского софта

priven wrote:
  Дело не в сложности исходной задачи ("электрон столь же неисчерпаем, как и атом"), а в сложности наших нынешних представлений о предмете. А последняя весьма тесно коррелирует с суммой усилий, затраченных на его изучение, - разумеется, в предположении, что решатели обеих задач примерно сопоставимы по интеллекту. Давайте все-таки не будем тешить себя иллюзиями, что разработчики ТРИЗ гениальнее всех на свете...
Давайте, Александр Ильич. Меня бы это вполне устроило.

Re: Эффективный алгоритм для изобретательского софта

Уважаемые коллеги, спасибо за публикацию статьи и интересные комментарии. 

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

Позвольте уточнить, что мы понимаем под универсальным алгоритмом в данном контексте. Это алгоритм, который одинаково успешно применяется и для решения конкретных производственных задач по исправлению недостатков, и для прогнозирования, и для обхода патентов, и для полномасштабного совершенствования технических систем и производственных процессов,  и для создания новых технических систем и т.п. Не исключено, что великие умы смогут создать такой алгоритм, и он даже будет работать. Но как-то вот получается, что эффективнее работать специально заточенными инструментами. Фотографии получаются лучше у фотоаппарата, а не у телефона. Читать книги удобнее в "читалке", а не в телефоне. Писать и редактировать тексты удобнее на компьютере с привычной клавиатурой, а не на телефоне. Хотя всё то же можно делать и с помощью универсального инструмента - телефона, но...  Мысль понятна, да?

Мы представляем наше видение алгоритма для исправления проблемных ситуаций, решения ситуативных задач. Таких задач в тризовской практике подавляющее большинство, и инструмент для их решения всегда востребован. Здесь мы стремились и будем стремиться к предельной конкретности. Об универсальности же можно говорить только в пределах данного класса проектов.

Нам важно ваше мнение. Судя по прежним обсуждениям, важно показать примеры задач, решенных с помощью алгорима. Их есть у нас и очень много, правда не все можно показать. Однако что-то можно, и мы будем просить Александра Владимировича выложить какие-то из этих разборов для обсуждения .
 

 

Re: Эффективный алгоритм для изобретательского софта

Цитата:

P.S. Про программу USESoft (автор и разработчик - Захаров Алексей Николаевич) авторы не слышали?

Положенный в ее основу алгоритм, носящий название "Универсальная Схема Эволюции" - эффективный, детализированный и универсальный. 

Уважаемый Павел, так понимаю, Алексеевич!

Спасибо, что Вы напомнили нам про программу и алгоритм "Универсальная схема эволюции". Мы слышали про программу USESoft, прочитали об этой программе в статье на сайте Методолог и в других источниках. К сожалению, большинство из прочитанного страдает некоторой общностью. Что понравилось, так это утверждение, что Универсальная схема эволюции - это почти что искусственный интеллект. Создание искусственного интеллекта - важнейшая научная проблема, и мы желаем Вам и Алексею Николаевичу всяческих успехов на этом поприще. 

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

1. Алгоритм чего именно разработан Алексеем Николаевичем?

2. Как он устроен, какие этапы включает и как с ним работать?

3. Примерчик бы. Работы универсального софта (ну или алгоритма) при решении разных типов задач?

Спасибо.

Re: Эффективный алгоритм для изобретательского софта

Цитата from Gregory Frenklah:

Это при том, что я с категоричностью авторов статьи  не согласен.

Каким требованиям должен соответствовать алгоритм, подходящий для софтверного продукта на базе ТРИЗ? Такой алгоритм должен:

быть специализированным: «заточенным» исключительно под решение задач по устранению недостатков.Действительно эффективный и детализированный алгоритм не может быть универсальным (например, одинаково подходить для задач по устранению недостатков и для прогнозных задач) [5].
методически поддерживать весь процесс решения: от уточнения проблемной ситуации до полного устранения недостатка и анализа улучшенной ситуации.
быть полностью логичным, без каких-то неточностей, неясностей и противоречий.
иметь одинаковую степень детализации на всех своих шагах.

 

Спасибо, Григорий, здесь действительно мы нечетко прописали. 

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

 

Re: Эффективный алгоритм для изобретательского софта

Nikolay Shpakovsky wrote:

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

<...>

Мы представляем наше видение алгоритма для исправления проблемных ситуаций, решения ситуативных задач. Таких задач в тризовской практике подавляющее большинство, и инструмент для их решения всегда востребован. Здесь мы стремились и будем стремиться к предельной конкретности. Об универсальности же можно говорить только в пределах данного класса проектов.

Проблемная ситуация: телефон (раз уж о нем зашла речь) всем хорош, но конкуренты научились делать такие же и откушивают у нас рынок, надо сделать лучше, чем у них (и, соответственно, чем у нас).

Проблема? Еще какая! Эппл с Самсунгом бьются над ее решением, миллиарды зелоеных бумажек на это вгрохивают...

Эта проблема ситуативная? Безусловно: в предыдущей ситуации всё было здорово, а теперь вот ситуация изменилась и проблема возникла.

В связи с этим, было бы интересно узнать:

(1) Решает ли предлагаемый алгоритм подобные ситуативные проблемы? Судя по тексту статьи, вроде как нет. Но хотелось бы получить ответ от уважаемого автора - я могу здесь ошибаться.

(2) Если не решает, то, в общем случае, какого рода проблемные ситуации он устраняет?

Что касается стекол, то самый первый метод расчета свойств стекол по составу позиционировался именно как универсальный, поскольку тогда никаких других стекол, за пределами 10-12-компонентной силикатной системы, человечество не знало (да и в этой системе знало лишь очень небольшую ее часть). А потом выяснилось, что эти стекла - только махонькая часть того, что может быть названо словом "стекло". И то, что тогда казалось "универсальным", стало - в пределах этой же самой области знания! - всего лишь маленьким, хотя и важным, частным случаем. Расширился горизонт наших знаний о предмете - соответственно, изменились и наши представления об универсальном и частном. Естественно, подобные примеры можно привести не только для стекол.

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

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

Быть может, все же имеет смысл подумать и о некоторой универсализации - хотя бы в тех пределах, какие Вы упомянули (прогнозы, обход патентов и т.д.), т.е. об объединении возможностей существующих методов в рамках какой-то более общей концепции?

P.S. Говорят, что за разработку некоей универсальной модели взаимодействия элементарных частиц могут Нобелевки давать... а она, эта "универсальная" модель, даже взаимодействие молотка с гвоздем толком описать не может... Непорядок - универсальная модель должна описывать взаимодействие ЛЮБЫХ частей в ЛЮБЫХ системах :))

Re: Эффективный алгоритм для изобретательского софта

priven пишет:

Проблемная ситуация: телефон (раз уж о нем зашла речь) всем хорош, но конкуренты научились делать такие же и откушивают у нас рынок, надо сделать лучше, чем у них (и, соответственно, чем у нас).

Проблема? Еще какая! Эппл с Самсунгом бьются над ее решением, миллиарды зелоеных бумажек на это вгрохивают...

Эта проблема ситуативная? Безусловно: в предыдущей ситуации всё было здорово, а теперь вот ситуация изменилась и проблема возникла.

Уважаемый Александр Ильич,

Вся проблема здесь в определениях. Сделать новый телефон, лучший, чем у конкурентов,-  это большой проект. Необходимо провести маркетинговые исследования, НИР, ОКР и много всякого разного...  А вот уже при выполнении этого проекта может возникнуть множество проблемных ситуаций, когда мы имеем один или несколько нежелательных эффектов, которые непонятно как устранить. Вот на их устранение и нацелен наш софт и алгоритм.

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

Мы считаем, что надо оставить кесарево кесарю, а сосредоточиться на той области ментальной деятельности, для которой собственно и создавалась ТРИЗ, - решении изобретательских задач. Попытки же "натянуть" ТРИЗ на всю маркетингово-инженерную деятельность изначально обречены... Как обречены и попытки создать ТРИЗ-среду без четкого понимания, что же такое сама ТРИЗ и для чего она предназначена. 

priven пишет:

В связи с этим, было бы интересно узнать:

(1) Решает ли предлагаемый алгоритм подобные ситуативные проблемы? Судя по тексту статьи, вроде как нет. Но хотелось бы получить ответ от уважаемого автора - я могу здесь ошибаться.

(2) Если не решает, то, в общем случае, какого рода проблемные ситуации он устраняет?

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

(2) Алгоритм самым подробнейшим образом описан в нашей книге "ТРИЗ. Практика целевого изобретательства". Но тут я согласен с коллегами, кто в ТРИЗ кого читает... кроме себя любимого :)

Если хотите, можно посмотреть разбор задачи о производстве стекла для мониторов по алгоритму вот здесь:

http://www.target-invention.ru/Data_RUS/Downloads/00008/Case-study_probl...

priven пишет:

Быть может, все же имеет смысл подумать и о некоторой универсализации - хотя бы в тех пределах, какие Вы упомянули (прогнозы, обход патентов и т.д.), т.е. об объединении возможностей существующих методов в рамках какой-то более общей концепции?

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

Re: Эффективный алгоритм для изобретательского софта

Уважаемый Николай Андреевич,

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

Если хотите, можно посмотреть разбор задачи о производстве стекла для мониторов по алгоритму вот здесь:

http://www.target-invention.ru/Data_RUS/Downloads/00008/Case-study_probl...

Решение Вы предложили хорошее и правильное, но:

1. После шага 1.1А стало очевидно, чте есть вредная система, выполняющая функцию "сжимать дленту стекла в поперечном направлении". Вопрос на засыпку: что должна делать полезная система? Ответ, по-моему, очевиден. Множество следующих шагов, по-моему, можно было безболезненно пропустить.

2. В стеклоделии похожая ситуация давно известна - это формование стекла на расплаве олова, так называемый флоат-процесс - тот самый процесс, к которому, согласно легенде, приложился ГСА. Там тоже проблема состоит в том ,что вредная система за счет поверхностного натяжения сжимает ленту стекла в поперечном направлении (правда, вид "дефекта" там другой, но это не суть), и тоже производительность недостаточная, и тоже, как и в Вашем случае (о чем Вы не написали), ролики не только повышают производительность, но заодно уменьшают толщину до требуемого размера (без них лента будет не только двигаться медленнее, но и получится слишком толстой). И там тоже решением оказались ролики под углом к направлению вытягивания. Можно было примиенить ФОП, причем, что называется, "не отходя от кассы" - прямо в пределах данной предметной области (стекольная технология).

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

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

 

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

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Действительно, после определения причины нежелательного эффекта ответ (вернее различные варианты ответов) становятся очевидными. Эффективный алгоритм должен предусматривать и такой поворот событий.
Что же касается легенды - пусть она останется на совести ГСА. Ещё по этому поводу можно прочесть в рубрике "Контрольный гвоздь" на этом сайте.

Re: Эффективный алгоритм для изобретательского софта

Коллеги, с вами просто страшно разговаривать - всё-то для вас очевидно  :)

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

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

priven пишет:

1. После шага 1.1А стало очевидно, чте есть вредная система, выполняющая функцию "сжимать дленту стекла в поперечном направлении". Вопрос на засыпку: что должна делать полезная система? Ответ, по-моему, очевиден. Множество следующих шагов, по-моему, можно было безболезненно пропустить.

Наверное вы правы, Александр Ильич. Если бы так была сформулирована функция вредной системы, это было бы хорошим указанием на то, что надо растянуть ленту стекла. Но, если вы посмотрите разбор внимательнее, то вредная машина там выполняет действие "Сморщивание полосы стекла". Это ведь не совсем сжатие, правда? Ролики препятствуют расширению стекла, вот что показывает структура вредной системы.

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

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

http://www.gnrtr.ru/Generator.html?pi=301&cp=3 

Там описана версия АИПС-2008, сейчас в ходу версия АИПС-2012, но принципиальное представление об алгоритме  получить можно.

priven пишет:

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

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

Да есть это всё у нас...  Использование основных линий развития предусмотрены на трех шагах алгоритма. А шаг 2.5 целиком и полностью предусматривает заполнение прогнозного поля при помощи линий и деревьев эволюции. Действительно, получается порой очень интересно. Мы это просто не акцентируем, потому что алгоритм отпозиционирован для решения задач, исправления проблемных ситуаций, а линии, которые вы законами называете, - просто один из многих инструментов для этого. Инструменты же, составляющие алгоритм, сочетаются у нас не "в какой-то мере", а целенаправленно и, хочется надеяться, логично... 

 

 

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:

Действительно, после определения причины нежелательного эффекта ответ (вернее различные варианты ответов) становятся очевидными.

Я бы даже сказал: некоторые варианты ответов могут стать очевидными.

Re: Эффективный алгоритм для изобретательского софта

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

Говорить, что я "называю законами" линии ЗРТС, как минимум, не вполне корректно, но к сути дела это отношения вроде бы не имеет. А вот пару-тройку других моментов хотелось бы прокомментировать.

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

<...>

Если задачу решает обычный инженер, то лучше идти по шагам алгоритма,  позволив нашей "решающей мельнице" (Solving mill) постепенно перемалывать задачу. 

Не сомневаюсь, что для специалиста по стеклу это лишнее и решение он видит, еще не начав решать - например, зачерпнув аналогичные задачи из своей ментальной ДБ. Но, простите, при чем тут алгоритм?

Давайте все же определимся, кто решает задачу. Я вижу здесь только два реальных (не экзотических) варианта:

(1) Задачу решает обычный инженер - специалист в своей предметной области. В этом случае отсылки к его "ментальной ДБ", особенно на этапе, когда становится понятным источник проблемы, представляются мне весьма и весьма целесообразными и я сам часто этим пользуюсь.

(2) Задачу решает профессиональный тризовец. Но в этом случае ему едва ли нужен столь "разжеванный" алгоритм.

 

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

 

priven пишет:

1. После шага 1.1А стало очевидно, чте есть вредная система, выполняющая функцию "сжимать дленту стекла в поперечном направлении". Вопрос на засыпку: что должна делать полезная система? Ответ, по-моему, очевиден. Множество следующих шагов, по-моему, можно было безболезненно пропустить.

Наверное вы правы, Александр Ильич. Если бы так была сформулирована функция вредной системы, это было бы хорошим указанием на то, что надо растянуть ленту стекла. Но, если вы посмотрите разбор внимательнее, то вредная машина там выполняет действие "Сморщивание полосы стекла". Это ведь не совсем сжатие, правда?

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

Ролики препятствуют расширению стекла, вот что показывает структура вредной системы.

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

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

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

Да есть это всё у нас...  Использование основных линий развития предусмотрены на трех шагах алгоритма. А шаг 2.5 как раз и предусматривает заполнение прогнозного поля при помощи линий и деревьев эволюции. Действительно, получается порой очень интересно. Мы это просто не акцентируем, потому что алгоритм отпозиционирован для решения задач, исправления проблемных ситуаций, а линии, которые вы законами называете, - просто один из многих инструментов для этого. Инструменты же, составляющие алгоритм, сочетаются у нас не "в какой-то мере", а целенаправленно и, хочется надеяться, логично... 

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

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

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Nikolay Shpakovsky wrote:

Коллеги, с вами просто страшно разговаривать - всё-то для вас очевидно  :)

А почему Вас это так удивляет?:)

По поводу Вашей статьи - я её раньше читал. Теперь ещё раз перечитал. Я бы не называл это алгоритмом, поскольку Вы привлекаете различные как ТРИЗ так и другие инструменты и подходы для выполнения каждого скорее даже не шага, а этапа. Это ближе к среде, в чём, кстати, ничего плохого нет. Правда, некоторые, знакомые мне вещи получили новое имя и рисунок:).

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Александр Кудрявцев wrote:

Gregory Frenklach wrote:

Действительно, после определения причины нежелательного эффекта ответ (вернее различные варианты ответов) становятся очевидными.

Я бы даже сказал: некоторые варианты ответов могут стать очевидными.

Если говорить вообще, а не о приведенном примере со стеклом - то согласен.

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:
Если говорить вообще, а не о приведенном примере со стеклом - то согласен.
Да, я конечно имел  в виду общий случай.

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

Поэтому, в частности, профессионалам в области стекла предложил бы не считать это решение эталонным и продолжить поиск передовых решений. Думаю что Николай Андреевич дал это решение именно как компенсирующее и достаточное именно в практическом смысле. На проектах не всегда удается поработать над проблемой столько, чтобы снять ее навсегда. Если говорить аллегориями - проект, это все же чаще всего лечение того, кто есть в реале, в рамках его финансовых и временнЫх возможностей, а не синтез идеального человека.

 

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Александр, давайте вернёмся к софту... Есть у меня сомнения, что им пользуются, как и многими другими подобными софтами.

P.S.Поясню. Софт и порядок работы с ним (софтом) должны экономить время конкретного решателя, группы решателей, фасилитатора, я не вижу значительной экономии. Про результат в виде решения задачи не говорю, поскольку результат можно получить и без софта. Например, экономией времени за счёт использования вместо таблицы Альтшуллера софта, выводящего на группу принципов можно пренебречь. Это при том, что работа с таблицей вместо меню параметров из софта имеет дополнительные преимущества. Ещё один софт, как хорошо организованный справочник - этакая электронная книга?

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

Gregory Frenklach wrote:
Если говорить вообще, а не о приведенном примере со стеклом - то согласен.
Да, я конечно имел  в виду общий случай.

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

Поэтому, в частности, профессионалам в области стекла предложил бы не считать это решение эталонным и продолжить поиск передовых решений.<...>

На проектах не всегда удается поработать над проблемой столько, чтобы снять ее навсегда. Если говорить аллегориями - проект, это все же чаще всего лечение того, кто есть в реале, в рамках его финансовых и временнЫх возможностей, а не синтез идеального человека.

И здесь я вижу еще одну важную, на мой взгляд, особенность: в известных мне инструментах ТРИЗ практически не уделяется внимания тому, чтобы целенаправленно искать именно решение, являющееся компромиссом между эффективностью и простотой реализации.

Да, конечно, в АРИЗ-85В при формулировке ИКР есть общеобязательные слова: "абсолютно не усложняя систему". Как идеал. А реально чаще всего оказывается, что чем эффективнее решение, тем оно сложнее (если только исходная система не была изначально плохо спроектирована). И как выбирать, что окажется в итоге лучше?

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

Если же попытаться снять проблему "полностью", то выяснится, что:

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

До сих пор я не видел в ТРИЗ ни единого инструмента, который бы позволял заранее определять, насколько близким к идеалунасколько далеким от него!) должно быть самое лучшее на данный момент решение из множества возможных. Александр Владимирович, быть может, Вы знаете такие инструменты?

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:

А нужен ли для этого ТРИЗ? Найденные решения без всякого ТРИЗ оцениваются по критериям эфективность, возможность и стоимость.

Григорий, а как насчет эффективности и стоимости самого процесса решения задачи? Тема, вроде как, про эффективные алгоритмы изобретательства, если я не ошибаюсь.

Ведь генерация, к примеру, 20 решений, из которых в итоге реализуется только одно, означает, что 95% результата выбрасывается в помойку. Самый ли это эффективный и дешевый способ решения задачи?

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

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Эффективный алгоритм изобретательства и эффективный алгоритм для изобретательского софта - вещи разные.

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

Re: Эффективный алгоритм для изобретательского софта

priven wrote:
До сих пор я не видел в ТРИЗ ни единого инструмента, который бы позволял заранее определять, насколько близким к идеалунасколько далеким от него!) должно быть самое лучшее на данный момент решение из множества возможных. Александр Владимирович, быть может, Вы знаете такие инструменты?

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

Естественно, что такие инструменты есть. Я не ищу их в АРИЗ-85В, и даже не очень понимаю, почему надо искать их там. АРИЗ - это тридцатилетней давности попытка сделать универсальный инструмент, но мы давно уже работаем не по этому универсальному инструменту, его отдельные части развились, отдельные отмерли, поскольку есть "общечеловеческие" средства достижения тех же самых задач, которые они пытались достичь.

В серьезных проектах в первую очередь это ТЗ - техническое задание. В нем определеляется, на что готов идти клиент. Скажем, он хочет снизить себестоимость продукта на 300 долларов и готов инвестировать в это не более 20 миллионов. Это ориентир. Если хотите, можете смотреть на это как на уровень идеальности. Есть и иные ориентиры. Также после каждого этапа работы полезно показывать результаты клиенту и обсуждать с ним возможные дальнейшие шаги. Некоторые из них он будет рубить, исходя из своих предпочтений или ограничений. Выявление этих предпочтений позволяет оконтуривать его понимание возможного поля решений, основанное на его личном опыте, имеющихся компетенций его сотрудников, готовности пользователей продукта  и прочих моментов.

 

И попутно попробую прокомментировать несколько моментов из Вашего письма.

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

Quote:
В примере со стеклом - да, конечно, эпюра вредных напряжений не тождественна эпюре компенсирующих, лист "не обладает жесткостью", и т.д., и т.д. (претензий к этому решению можно предъявить множество). Но всё это не главное, а главное - то, что данное решение снимает проблему в достаточной мере и простейшим путем. И в этом смысле его можно считать эталонным.
Опять же, разница в стилях - Вы готовы считать такое решение эталоным, так же как универсальным свой метод расчета стекол, более широкий чем конкурентные. Если так определить и с этим согласиться, то будет нормально. Я не считаю такой решение эталонным, считаю его допустимым, разрешенным, приемлемым. Но, повторюсь - вопрос вкуса.

Quote:
Если же попытаться снять проблему "полностью", то выяснится, что:

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

Re: Эффективный алгоритм для изобретательского софта

priven пишет:

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

Считаю что Вы правы.

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

Мы здесь опять углубляемся в детали, но делать нечего. Как устроен софтвер Solving Mill? Никакая это не электронная книга. Софт имеет пять уровней - 2 "боевых" и 3 поддерживающих. Основная часть первого уровня - это темплейт, в котором решатель собственно и работает с задачей. Темплейт - это последовательность шагов решения задачи в соответствии с алгоритмом. На каждом шаге темплейта нужно получить определенный результат. Второй уровень - это набор так называемых операторов, использование которых помогает при заполнении темплейта. Третий уровень - это подсказки для заполнения ячеек темплейта, четвертый - хелп, пятый - Е-learning course.

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

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

То есть - темплейт указывает, что нужно сделать и какой результат получить на каждом шаге. А вот как это сделать - тут помогают операторы. А уж решатель сам оценивает свои силы и решает, как глубоко нужно погружаться в софтвер. Можете решить задачу без операторов - милости просим!  Желаете сделать это вообще без софтвера, каким то другим образом, - как мы можем кого-то заставить?

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Сравнил с описанием своего софта образца 1992/93 года ещё под DOS 3...:)

Система  поддержки анализа проблем и поиска идей их решения
 1. Ситема поддержки анализа проблем и поиска идей их решения включающая алгоритм решения и базу примеров, отличающаяся тем, что с целью повышения эффективности работы с системой пользователей с различным уровнем подготовки алгоритм решения одновременно представляет собой ключ поиска в базе примеров.
2. Ситема по пункту 1. отличающаяся тем, что существует возможность поиска по неполному ключу с его последующим автоматическим дополнением.
3. Ситема по пункту 2. отличающаяся тем, что на каждый пример из базы существует возможность выхода с помощью нескольких ключей.
4. Ситема по пункту 3. отличающаяся тем, что существует возможность подстройки системы под пользователя путём добавления своих примеров в базу.

В системе главное это примеры. Причём не единичные а системные. На одно и тоже решение можно выйти в рамках ТРИЗ разными путями, используя различные инструменты: стандарты, приёмы, эффекты, приёмы разрешения ФП. Таким образом пример превращается в систему, замыкающую на себя различные пути  и различные инструменты.
При обычном подходе решение выглядит "плоско" а реальные решения всегда "объёмны". Такой подход позволяет связать между собой различные примеры. Например у двух примеров может совпадать один из путей ведущих к решению или часть пути. Построенная таким образом база примеров превращается из базы ДАННЫХ в базу ЗНАНИЙ
 

Распределение работы между с и стемой и человеком...
1. Человек в текстовом поле описывает ситуацию;
2. Человек определяет тип задачи;
3. Система выбрасывает набор текстовых полей, в зависимости от типа.
4. Человек выбирает метод поиска ТРИЗ инструмента.
5. Система выбрасывает различные наборы текстовых полей  и/или меню
6. Человек заполняет текстовые поля и/или делает выборы в меню.
7. Система в качестве рекомендации предлагает список ТРИЗ инструментов, в зависимости от выбора в меню.
8. Человек выбирает инструмент.
9. Система предлагает примеры соответствующие выбору
(все выборы, которые сделал человек во всех меню представляют собой путь решения, а текстовые поля системой не учитываются)
10. Человек выбирает пример и входит в базу примеров. Далее у него есть возможность гулять по базе и "примеривать" различные пути на свою задачу.
11. Человек может сразу войти в базу примеров, что опытный пользователь и будет делать. Тогда, выбрав подходящий путь, человек может примерить его на задачу и уже потом заполнить текстовые поля.

Моя ситема работает (работала) на четырёх уровнях - не было e-learning и поэтому пришлось "обычный" курс разрабатывать..

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

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

Re: Эффективный алгоритм для изобретательского софта

Александр Кудрявцев wrote:

В серьезных проектах в первую очередь это ТЗ - техническое задание. В нем определеляется, на что готов идти клиент. Скажем, он хочет снизить себестоимость продукта на 300 долларов и готов инвестировать в это не более 20 миллионов. Это ориентир. Если хотите, можете смотреть на это как на уровень идеальности. Есть и иные ориентиры.

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

Кто из нас прав? И как это можно определить методическим путем? Если есть вот это конкретное решение - то надо ли смотреть еще какие-то, или лучше остановиться на нем и не тратить зря время? Что на этот счет говорит (или может сказать) ТЗ?

Решений с помощью ТРИЗ можно найти множество - но каждое из них надо будет (а) найти, (б) сформулировать, (в) проанализировать, плюс риск ошибиться в выборе...

Я не хочу находить и анализировать 20 решений, а хочу сразу найти одно, но лучшее в данной конкретной ситуации. Это разве противозаконное желание?

Готов поверить, что это желание на данном этапе развития ТРИЗ пока еще недостижимо. Но идеал, в моем представлении, лежит именно где-то здесь...

Re: Эффективный алгоритм для изобретательского софта

Nikolay Shpakovsky wrote:

Как устроен софтвер Solving Mill? Никакая это не электронная книга. Софт имеет пять уровней - 2 "боевых" и 3 поддерживающих. Основная часть первого уровня - это темплейт, в котором решатель собственно и работает с задачей. Темплейт - это последовательность шагов решения задачи в соответствии с алгоритмом. На каждом шаге темплейта нужно получить определенный результат. Второй уровень - это набор так называемых операторов, использование которых помогает при заполнении темплейта. Третий уровень - это подсказки для заполнения ячеек темплейта, четвертый - хелп, пятый - Е-learning course.

Николай Андреевич, я рад, что в чем-то наши с Вами позиции совпали. Что касается деталей - надеюсь, на ридной Корейщине нам будет о чем поговорить. В любом случае желаю Вам всяческих успехов!

Re: Эффективный алгоритм для изобретательского софта

Gregory Frenklach wrote:

Решение мини задачи, удовлетворяющее критериям ИКР, и есть то, что Вам нужно.:)

А если не удовлетворяет или не совсем удовлетворяет - что тогда?

А если ИКР сформулирован избыточно (типа "полностью устранить деформацию", когда реально надо всего лишь ее уменьшить раза в четыре, но про разы никто не знает заранее) - что тогда?

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя Gregory Frenklach.

Лично я для таких случаев использую PSM (problem situation mapping) но можно и классикой обойтись - т.е...
а. Если не удовлетворяет то:
1.Либо формулируете мини-задачу для так называемой вторичной задачи (всё остаётся, как есть, но Вы удовлетворены)
2.Либо формулируете мини задачу задачу на более высоком уровне (всё остаётся, как есть но нежелательный эффект более высокого уровня исчезает)
б. Если завысили требования - значит не разобрались в ситуации - назад разбираться:)
 

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя ВЭПЭ.

Согласно условия,

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

Могут ли здесь образовываться места будущих морщин?

Могут и образуются,

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

Поэтому "более" ИКР-ное решение связано не с роликами, ибо они вторичны по ходу движения потока стекла, а с направляющей.

 

Re: Эффективный алгоритм для изобретательского софта

Изображение пользователя GIP.

ВЭПЭ wrote:

Поэтому "более" ИКР-ное решение связано не с роликами, ибо они вторичны по ходу движения потока стекла, а с направляющей.

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

Re: Эффективный алгоритм для изобретательского софта

ВЭПЭ wrote:

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

Нет. Способ формования стекла здесь существенно изменен не был - то же самое было и на 70 см ленте, и то же самое потом было сделано на 3-метровой линии.

ВЭПЭ wrote:

Могут ли здесь образовываться места будущих морщин?

Могут и образуются,

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

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

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

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

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

Re: Эффективный алгоритм для изобретательского софта

priven пишет:

Решений с помощью ТРИЗ можно найти множество - но каждое из них надо будет (а) найти, (б) сформулировать, (в) проанализировать, плюс риск ошибиться в выборе...

Я не хочу находить и анализировать 20 решений, а хочу сразу найти одно, но лучшее в данной конкретной ситуации. Это разве противозаконное желание?

Готов поверить, что это желание на данном этапе развития ТРИЗ пока еще недостижимо. Но идеал, в моем представлении, лежит именно где-то здесь..

Классная идея - найти одно самое лучшее решение. Вот только кто его будет искать и какими средствами?

Я не хочу находить и анализировать 20 решений...   кто этот "я"?   Заказчик или решатель? Или кто-то еще?

Использовать для поиска наилучшего решения только инструменты ТРИЗ - в рамках взаимодействия "заказчик-решатель" - это даже обсуждать не хочется. Всё, что можно для этого, предусмотрено и делается, при ясном понимании неопределенности, которая неизбежно таится в самой постановке задачи. Дело в том, что заказчик никогда не может  сразу, до начала работы с задачей, озвучить всё: ресурсы, приоритеты, свои предпочтения, явные и неявные ограничения и много других нюансов, которые как раз и позволяют выбрать решение, близкое к идеальному в данной конкретной ситуации. Это трудно сделать даже решателю, решающему собственную задачу. Устраивать исследование всех вариантов идеальности - решать же некогда будет...  Да и зачем, если заказчик уже владеет этой информацией? Просто он этого сам иногда не понимает...

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

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

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

Re: Эффективный алгоритм для изобретательского софта

Николай Андреевич, я согласен практически со всем, что Вы написали в последнем посте. И что задача никогда не бывает понятной заказчику (иначе он сам бы ее и решил), и что несколько вариантов более оптимальны, чем один, по соотношению "цена / качество" (решателю, особенно внешнему, не всегда просто выбрать самый лучший вариант, а заказчик может его выбрать с учетом своей информации, до решателя по разным причинам не доведенной), и т.д.

Но, говоря про поиск "одного лучшего" решения, я как раз и говорил про идеальный конечный результат - на что Вы возразили, по существу, ровно то самое, что я ранее возражал Вам и Александру Владимировичу: что самое лучшее на данный момент решение не обязательно ближе других к ИКР.

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

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

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

Subscribe to Comments for "Эффективный алгоритм для изобретательского софта"