Господа!
Наша компания, Pretium Innovation, LLC начала подготовку к разработке и выпуску третьей версии программного обеспечения Guided Innovation Toolkit (GIT) название русской версии "Инноватор".
Этот проект инициирован накопившимися предложениями по усовершенствованию от наших постоянных пользователей, назревшим переходом на платформу дотнет и запросах на различные языковые локализации этого ПО.
У меня возникла идея использовать площадку сайта Методолог как эксперимент с Open Innovation (Открытыми Инновациями). Все идеи по усоверщенствованию софта будут открыто обсуждаться, не смогут быть собственностью какой-то одной компании т.к. открыты для широкого круга лиц (public domain). Определенные путем такого открытого обсуждения спецификации лягут в основу дезайна будущего продукта.
Как вам такая идея?
Прошу высказываться...
ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Кроме Автоматизации рутины ничего более общего. Давайте от печки. Чтобы софт продавался он либо должен железно стыковаться с другими софтамив процессе, либо все нестив себе.
Как люди интуитивно решают проблемы? (Дурацкое тыканье МПиО оставим идиотам). Вот что говорят психологи:
А это то как мы пытамся помочь интуитивному процессу:
Снизу показан основной метод-оригинатор используемый на данном шаге.
На каждом шаге свои цели, задачи, инструменты и соответственно программы.
Я предлагаю оценить этов целом. а потом уже идти по-шагово.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Мое почтение.
В этой формулировке неявным образом присутствует уже известный ответ, поскольку для минимизации нужно знать оба "конца пути". Иначе это будет вероятностное знание, обзываемое МПиО.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Подобными темами занимается когнитивная психология. И когнитивистика вообще.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Тэ-экс. С моей колокольни:
1. Чтобы софт продавался, он прежде всего должен быть доступен. Доступен прежде всего в смысле освоения. Он должен в этом смысле быть модульным, каждый модуль - это какие-то блоки действий, которые с помощью софта облегчаются или упрощаются. Среди них всегда есть ключевые, без освоения которых невозможно работать с системой в целом. И вот такие модули должны быть доступны вообще бесплатно как отдельные программки. Секрет комплекса - в связи модулей и их комбинациях.
2. Что касается инноваций и "рутинных процедур". ПО должно помогать - изобрести инновацию, или внедрить ее. Это ведь разные задачи. И соответственно разная "рутина". Свертка интуитивного процесса на данный момент в когнитивной науке рассматривается как вычленение основных поисковых механизмов, потому что человек мыслит "поисковыми блоками", или, скажем так, интуитивный процесс состоит в приложении к ситуации разных поисковых алгоритмов, доступных человеку. Некоторое количество их, насколько мне известно, уже описано в литературе. Безобразие заключается в том, что перебор поисковых алгоритмов в приложении к ситуации происходит в фоновом режиме (background search).
3. Еще нюанс. Когнитивщики определяют ситуацию (в отличии от задачи) как такую логическую (или паралогическую) конструкцию, в которой цель есть правило достижения других целей. Поэтому задачами интуитивное мышление не интересуется.
4. То есть речь идет о поиске взаимосвязанных цепочек таких правил, каждая из которых может быть представлена как цель. Взять "инновацию". Придумать новое - это не придумать отличие от старого. Это значит задать правило, превращающее цель системы в новое правило. Для примера, степень идеальности - инновация, правило (поскольку с.и. может быть увеличена или уменьшена по определенной процедуре). Но здесь есть проблема: увеличение степени идеальности системы как правило, увеличивает рассогласованность связанных с ней систем и ближайших надсистем. Но эта рассогласованность правилом не является, поскольку нет процедуры уменьшения - увеличения рассогласованности в зависимости от увеличения-уменьшения степени идеальности. Поэтому, кстати, интуиция "проскальзывает" мимо ТРИЗовских алгоритмов: если нет согласованности правил, поисковые механизмы такие ситуации обходят в автоматическом режиме.
5. Поэтому первый пункт Вашей схемы (определение целей) можно было бы видоизменить как "определение целей как согласованных правил достижения этих целей". Подобная конструкция, возможно (!) будет более доступна для "интуитивно понятного интерфейса" взаимодействия человека и системы.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Вот видите - а я считаю, что два: выполнить функцию, отказавшись от системы, связанной с нежелательным эффектом, или, сохранив систему, устранить нежелательный эффект. И это вовсе не "высокий уровень обобщения" - сплошная конкретика. А пример "высокого уровня обобщений" это, например, разговор о системно-эволюционных или неэволюционных преобразованиях и/или различного рода "генезах" (стасигенезе, квантигенезе, квалигенезе, изогенезе, квантиизогенеза... и т.д. - могу и дальше "ругаться") Давайте оставим такой "высокий уровень" для себя, а договариться будем о конкретике (для нашей области, конечно).
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Lynx,
Вот об этом я и говорю. Понял всё до середины второго пункта.:)
Дальше могу только догадываться. Может правильно догадаюсь, а может и нет.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Может, и правильно :)
Там главное в 3-м пункте. Цель должна быть представлена как правило достижения другой (следующей) цели. По крайней мере это способ проверки. Если машина делает болт, то цель этой системы (машины) - в соединениях на болтах в других системах. Это упрощенно. Но если проверять так системы, очень многое упрощается почти до "интуитивного" уровня.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
А человеческий мозг и осуществляет то динамическое системное деление, о котором я говорю ниже.
В.М. Капустян, Ю.А. Махотенко. «Конструктору о конструировании атомной техники. Системно-морфологический подход в конструировании.», Москва, Атомиздат,1981 г.
В электронном виде можно посмотреть здесь. Там же есть диссертация Капустяна. В принципе, представляет собой попытку реализации многомерного морфологического ящика на базе ЭВМ тех лет. На мой взгляд, содержит целый ряд интересных суждений, хотя, некоторые коллеги относятся к этой книге с иронией.
Не думаю, что расходимся. Известно, что чтобы объединиться (интегрироваться) необходимо сначала хорошенечко размежеваться, а то не очень понятно, что интегрируется то.
Я использую графический язык для описания автоматов, предложенный Шалыто А.А., с некоторыми модификациями. Хотя, чаще собственный функциональный язык описания автоматов с последующей реконструкцией в графическую нотацию. У Шалыто есть и вариант представления в подмножестве UML диаграмм и объектном представлении.
Это вовсе не ТРИЗ, но подход мне очень нравится.
С уважением, Александр.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
И моё почтение.
Ответ на какой вопрос Вы имеете в виду?
Зачем надо знать оба конца и что Вы, опять же, имеете в виду?
Опираясь на общесистемные закономерности и используя адаптивные технологии можно спускаться к неизвестному концу. В этом случае мы минимизируем помеху, отсекаем шум или, в нашем случае, не имеющие перспектив варианты МПиО. Получается, что можно знать не о конце, а о системных свойствах шума, что, признайте, несколько о другом говорит.
Собственно, на мой взгляд, ТРИЗ, и АРИЗ в частности, это и делают. На основе знания системных закономерностей они позволяют на огромном поле вариантов МПиО отсечь то, что уже отсекли до Вас, отсечь, то, что заведомо не ведёт к цели, и, в итоге, либо применить уже известное по прямой аналогии, либо остаться со значительно уменьшенным полем вариантов, на котором МПиО вполне работает.
С уважением, Александр.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Для меня это не праздный вопрос, поскольку задумался над ним при попытке понять и попробовать (правда, скорее в учебных целях) применить ФСА+ТРИЗ в интерпретации Литвина, Герасимова и Ко (1991г.)
С уважением, Александр
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Это не контр-пример. Я действительно это использую.
Есть два типа проблемных ситуаций:
1. Первый возникает, когда нужно выполнить функцию, а средство её выполнения отсутствует или неизвестно.
2. Второй связан с нежелательным эффектом в уже существующей системе
В случае проблемной ситуации первого типа рекомендуется:
1.Сформулировать функцию (действие) для реализации которого отсутствует средство.
2.Определить объект функции
3.Выбрать какое-нибудь более или менее подходящее средство для выполнения функции
4.Определить нежелательный эффект, который возникает, если использовать это средство.
В случае проблемной ситуации второго типа рекомендуется:
1.Определить нежелательный эффект - источник проблемы.
2.Определить элемент связанный с нежелательным эффектом
3.Сформулировать функцию элемента системы, связанного с нежелательным эффектом
4.Определить объект функции элемента, связанного снежелательным эффектом.
Есть два возможных направления решения задачи:
1.Выполнение функции без носителя функции (связано либо с изменением объекта либо с получением информации об объекте функции)
2.Устранение нежелательного эффекта (связан либо с вредным взаимодействием либо с недостаточной эффективностью)
Далее к каждому направлению можно привязывать стандарты, приёмы ТП, эффекты или использовать ресурсы, наделение которых требуемыми свойствами для 1) или 2) приводит к физическому противоречию, но не всегда.
Например, стандарты могут быть разделены на четыре группы, две из которых привязываются к первому направлению решения задач, а две оставшиеся ко второму.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Спасибо! На общем уровне все, вроде бы, понятно. Но у меня вопрос, с которого я на самом деле и начал. Вот Вы пишите:
Но почему в случае "второго типа" менять можно только объект функции, а не само средство? Пусть не ГПФ (иначе совсем будет другая ТС), а для какой то полезной функции элемента ТС. При этом в целом начнет действовать Ваш алгоритм "первого типа". И в таком случае очень важно отделить саму функцию (полезное изменение параметра) от производящего его элемента (воздействия). Именно удивившись с одной стороны разделению параметра от действия при подведении к функции, но отсутствии такого разделения в самом определении и примерах в методички Литвина, Герасимова и др. я и задумался о последствиях такого разделения. Пришел в выводу что ФСА при этом может идти не "снизу вверх" (от функций самой низкого уровня с целью сворачивания "последнего" элемента), а "сверху вниз" (т.е. начиная от ГПФ искать другие варианты "воздействия"/элементов, которые более качественно выполняют ПФ и лишены ВФ). По примерам получается, что даже в классическом применении ФСА (ледоход, лампочка, электрокипятильник и др. примеры) такое разделение достаточно существенно.
В связи с этим вопрос: в связи с чем у Вас такое очень жесткое различение двух типов проблемных ситуаций?
С уважением, Александр
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Александр, а я вовсе не настаиваю, чтобы везде был ТРИЗ. Я хочу чтобы GIT помогал людям в ситуаации "пойди туда незнаю куда, поменяй то незнаю что", к коим и относятся инновации.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Есть таки третий вариант. Улучшить имеющуюся систему, скажем на 5%, с минимальными изменениями.
Помните притчу: 2 человека встретили тигра и убегают. Один говорит - зачем бежать. Мы не можем бегать быстрее тигра. Второй ответил - мне не нужно бежать быстрее тигра, мне нужно бежать быстрее тебя.
Классическая систуации бизнес конкуренции - на 5% улучшить имеющееся лучше чем строить новый завод на другом принципе.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Оно не жёсткое - просто я не дал примечание в котором указал, что если трудно выбрать, к какому типу отнести проблему к первому или второму - выбирайте тот, который с вашей точки зрения больше подходит. Ведь в любом случае два типа дальше сводятся к одному. А затем уже выбирается направление решения. Я чувствую, что должен дать ещё кое-что - картрирование проблемной ситуации:
Первичная постановка задачи
Существует два типа задач:
а) Необходимо выполненить ту или иную функцию, а системы либо нет, либо она неизвестна.
Например, как обнаружить трещины в стеклянной пластине? Проблема состоит в том, что стеклянная пластина закрыта с двух сторон пластинами из алюмины. Как быть?
б) Необходимо устранить нежелательный эффект в существующей системе.
Например, при нанесении слоя металла на керамическую пластину через прижатую к ней маску, металл попадает также и под маску. Причина в том, что маска приподнимается над пластиной. Как быть?
В случае а) мы определяем:
•Функцию
•Объект функции
•Более или менее подходящую известную систему для выполнения функции
•Нежелательный эффект, который возникает если использовать эту систему;
В случае б) мы определяем:
•Нежелательный эффект
•Элемент, связанный с нежелательным эффектом
•Функцию элемента
•Объект функции
Построение карты проблемной ситуации
После первичной постановки задачи можно строить "карту" проблемной ситуации.
Например: Мы не можем повысить скорость самолёта из-за сопротивления воздуха крыльям.
Элемент, связанный с этим нежелательным эффектом - крыло.
Функция крыла - поднимать и поддерживать корпус самолёта(в процессе взлёта, полёта и посадки).
Объект функции - корпус самолёта.
•Строя карту для "южного направления" мы будем рассматривать нежелательные эффекты и элементы с ними связанные, которые появятся если устранять первичный нежелательный эффект (повышенное сопротивление воздуха) известными методами.
Например: Если мы уменьшим площадь крыла - появится другой нежелательный эффект - требуется высокая взлётная скорость самолёта, требующая большого разбега -и елемент, связанный с этим нежелательным эффектом взлётная полоса (слишком длинная).
•Строя карту для "северного направления", мы будем рассматривать нежелательный эффект и элемент с ним связанный, которые появится если мы удалим элемент связанный с первичным нежелательным эффектом и/или не бдем выполнять его функцию ( поднимать и поддерживать корпус самолёта в процессе взлёта, полёта и посадки).
Например: Мы удалили крылья. Теперь нет проблемы высокого сопротивления воздуха, но ничего не держит корпус самолёта.
•Строя карту для "восточного направления", мы будем рассматривать нежелательный эффект, который является причиной первичного нежелательного эффекта.
Например: Возможно причиной высокого сопротивления являются вихревое движение воздуха, связанное с качеством поверхности крыла... А элемент, связанный с этим нежелательным эффектом - часть поверхности крыла...
•Строя карту для "западного направления" мы будем рассматривать нежелательный эффект который появится если не устранять первичный нежелательный эффект.
.
Например: Потери времени из-за низкой скорости самолёта и связанный с этим нежелательным эффектом элемент.
Для каждой из проблем могут рассматриваться два возможных направления решения:
•Устранение НЭ
•Измерение и/или обнаружение НЭ
Например, износ инструмента в обрабатывающем центре определяется по току электродвигателя. В соответствии с этим адаптивная система изменяет режимы резания. Допустим, что причина роста тока двигателя в перегреве подшипников, что приводит к неправильной оценке износа инструмента.
Тогда можно выбрать одно из двух направлений решения:
•Попытаться устранить нежелательный эффект - перегрев подшипников
•Попытаться онаружить/измерить перегрев подшипников.
Как проблему так и направление её решения выбирают в зависимости от имеющихся в распоряжении ресурсов.
Примечание: Выбранная для решения проблема должна быть переформулирована (см часть "Первичная постановка задачи")
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Спасибо за развернутый ответ, Григорий!
Я чувствую, что этот вопрос (разные направления - "стороны света" - функционального анализа. Или только проблемы?...) лучше вынести в отдельную ветку. В принципе я уже пару недель как собираю потихоньку материал для этого. И раз вопрос все же осмыслен, то попробую через какое то время его развернуто изложить в новой ветке
С уважением, Александр
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Господа,
Я тут мимоходом разрешил одну проблему: для обеспечения продуктивной дискуссии нужно дать доступ участникам к комерческим материалам, но доступ требует создания индивидуального login для каждого пользователя, что трудоемко.
Решение проблемы в разделении противоречивых требований по условию: Материал доступен читателям Метолога.
Прошу в веб-книжку Активатор (Guided Brainstorming Toolkit)
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Сергей, все же не удалось до конца понять, в чем состоит особенность Вашего подхода к формулированию противоречий. Не могли бы Вы привести пример: ТП и ФП
Спасибо.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Если говорить об особенностях, то я опираюсь на то, что специалисты знают (или легко могут узнать) что хорошо, что плохо. Я не разделяю АП-ТП-ФП. Это трата времени на анализ, результаты которого легко перекрываются генережкой идей. Я предлагаю пользователям построить причинно-следственные цепочки полезных и вредных функций, и там где они пересекаются возникают противоречивые функции (с полезным и вредным выходом). Т.е. Функции выполнять которые НАДО, чтобы получать полезный выход, и НЕ НАДО, чтобы не возникал вредный выход. Далее идет применение приемов организованных по типам разделения противоречивых функций в пространстве, времени, структуре, по условиям - что подразумевает и их соответсвующие комбинации.
При такой схеме выдвигаются все возможные способы разрешения ФУНКЦИОНАЛЬНОГО противоречия, из которых потом выбирается лучший.
Хлопот меньше, а результат лучше или тотже, что и по АРИЗ.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Спасибо. Но хоть какой-то пример можно увидеть? А лучше бы парочку. Потому что пока похоже скорее на декларацию о намерениях, причем в области, которой я совершенно не касаюсь - я не готов оценивать сравнительную эффективность Вашего подхода и каких-то классических. Речь о том, как у Вас формулируется ТП.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Александр, я дал ссылку на веб-книжку "Активатор" - там более сотни примеров в разделе "Разрешить противоречие" и разобранные кейсы.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Сергей, спасибо за "наводку".
Я посмотрел варианты противоречий. По моему Вы совершенно верно не называете свою разработку ТРИЗ, и несколько опрометчиво называете приведенные ниже конструкции противоречиями.
Функция "нужное количество замазки" должна обеспечить функцию "замазка щелей" и не должна вызывать "плохая заделка".
Функция "Высокая кабина" должна обеспечить функцию "улучшать обзор на трассе" и не должна вызывать "невозможность поезда под мостами"
Что у Вас понимается под обозначениями: функция "высокая кабина", или функция "нужное количество замазки", понять пока не смог. Если дадите разъяснения - буду благодарен.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Я собирался подробно это раскрывать, но появилось интервью с Борисом Злотиным, где он, как всегда коротко и емко, осветил эволюцию подхода к использованию функции.
При генерации идей важны 3 момента:
1. Формула идеальности, как отношения полезных и вредных функций отражает отношение суммы пользы к факторам расплаты. Для снятия психинерции под пользой и вредом лучше рассматривать не элементы, а действия или процессы - легче искать альтернативны для выполнения функции.
2. Когнитивная психология рассматривает процесс возникновения новых идей как построение и трансформацию динамических мысленных моделей (образов). Для того чтобы выбрать правильный образ и не растекаться мыслью по древу нужно как-то сфокусироваться на определенной части системы, которую мы будем мысленно менять. Если таких моделей несколько, то им лучше дать имена, чтобы не путаться, можно цыфры. Мы рекомендуем делать это в форме функций, но это не обязательно.
3. Если текст "нужное количество замазки" лучше описывает динамичный образ чем "введение нужного количества замазки в шель между плитками", то не проблема нарушить правило описания функции.
Возможно вы правы и мне есть смысл отказаться от термина противоречие и ввести что-нибудь типа "ключевая функция" или лучше "конфликтная функция", оставив в стороне все эти трудно понимаемые пользователями сложности с АП-ТП-ФП в ТРИЗ.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Александр, прочел свой предыдущий пост и остался недоволен. Я не знаю как объяснить. Лучше расскажу историю о том как я пришел к тому, что есть, а уж вы решайте сами.
Мы работали с компанией "Боинг". Когда объясняли функциональную модель, они вдруг сказали, что это же IDEF. Я не знал что это такое, полез в инет и с ужасом обнаружил, что это целый стандарт принятый министерством обороны, обязательный для всех проектов, регламентирующий правила написания функций и процедуры построения моделей. Более того, выяснилось, что разработан специальный софт, внимательно следящий за этими правилами и не позволяющий непрвильно вводить функции или допускать ошибки в построении моделей. (Желающие могут найти стандарт IDEF0 в инете и почитать - нулевой стандарт описывает основные правила).
На следующий день я шел на встречу как на эшафот - сейчас мне расскажут, что все наши наработки давно известное фуфло и накрылся наш контракт. Каково же было моё удивление, что наш софт вызвал живейший интерес, а после завершения 5-ти дневного курса ещё и неуёмные восторги.
Я аккуратно поинтересовался на тему IDEF и мне объяснили, что IDEF используется в фирме для наказания неугодных. Провинился - иди строй IDEF модели. Выснилось, что система призванная структурировать процесс и повышать креативность, на самом деле оказалась губительницей творчества. Вместо того, чтобы думать о решении проблемы или улучшении системы специалисты вынужденны тратить уйму времени на то, чтобы правильно записать функцию на языке понятном тупому компьютеру. Излишняя формализация начисто убила возможность творчески мыслить. Наша же система с "нежесткими правилами" позволяла быстро вычленить конфликт, организовать и систематизироать дискуссию по проблеме группы экспертов, нащупать ядро проблемы и, что интересно построить прототип для IDEF.
Эта история и послужила толчком к тому, чтобы фокусироваться на том "о чем думать", вместо того чтобы "как записывать".
Все ли понимают ситуацию одинаково?
Все ли согласны, что проблемосодержащая система функционирует именно так?
Все согласны с "условным" названием функций?
Все согласны с характером и структурой связей между функциями?
Если да, то группа готова к штурму проблемы.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Мы имеем тут дело с пониманием полезной/вредной функции не как триады (субъект, действие, объект), а как какого-то положительного/отрицательного эффекта, который может описываться и как действие, и как свойство, и как состояние.
Привычка чётко формулировать функции скорее мешает, чем помогает при таком подходе.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Сергей, я с Вами полностью солидарен - я тоже, если так можно выразиться, "остался недоволен", иными словами, в очередной раз так и не не понял, что это за функция - "высокая кабина". И почему вообще это функция. Хотя, в нашем коллективе уже появился расхожий термин - "высококабинить", но означает он вовсе не хорошую обзорность на дороге.
Про рассказ - занятно, но не убедительно.
Во первых, если Вы рассказывали на Боинге то, что было действительно похоже на IDEF, который они ненавидели, то непонятно, откуда у слушателей появились восторги. Если же это была Ваша система, то совершенно непонятно, чего в ней общего с такой структурированной системой, как IDEF и сходных с ней инструментов ( ARIS и прочие).
Во вторых, непонятно, почему в функциональном анализе Вы видите только "как записывать" и противопоставляете это "о чем думать"? Из этой фразы можно сделать вывод, что такой инструмент как функциональный анализ, Вами в свое время был не понят и бьетесь Вы не с ним, а с его собственным пониманием, в котором места "о чем думать" не нашлось.
В третьих, как на основании фразы типа: Функция "дверной глазок" должна обеспечить функцию "наблюдение" и не вызвать функцию "информация об отсутствии" удается понять, с чем все согласны, и что достигнуто единодушие в понимании проблемы?
В общем, вопросов много, но главное понятно: функция "головной мозг" должна обеспечивать функцию "мышление" и не вызывать функцию "потеря чувство меры".
Вот как-то так.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Ой! Боюсь, сейчас Фил появится для разъяснения конфликтного анализа :)
С уважением, Александр.
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Нет, вопросов не много.
1. Дать правило определения функции
2. Почистить примеры в соответсвии с правилом.
За критику спасибо. У меня глаз "замылен", просто не обращал внимания на несуразности в примерах.
Сергей Малкин
www.pretiumllc.com
Re: ТРИЗ-Софт. Guided Innovation Toolkit 3.0
Сергей, приветствую!
Правило почти 20 лет как официально существует и успешно используется.
http://www.triz-summit.ru/ru/section.php?docId=3952
ТРИЗ-ФСА - Методические рекомендации 1991
УДК 658.011.47 (083,13) РГАСНТИ 45.01.75
Основные положения методики проведения функционально-стоимостного анализа: Методические рекомендации. — М.: Информ— ФСА, 1991. —40 с.
...
2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
...
2.12. Функция — проявление свойств материального объекта, заключающееся в его действии (воздействии или взаимодействии) на изменение состояния других материальных объектов.
2.13. Носитель функции — материальный объект, реализующий рассматриваемую функцию.
2.14. Объект функции — материальный объект, на который направлено действие рассматриваемой функции.
2.15. Полезная функция — функция, обусловливающая потребительские свойства объекта.
2.16. Вредная функция — функция, отрицательно влияющая на потребительские свойства объекта.
Цели ясны = почистить примеры.
Задачи определены = почистить в соответствии с правилом.
За работу, товарищи!
Примечание:
В стандарте IDEF0 вот такое определение функции:
2.24 Функция: Активность, процесс или преобразование (моделируемые блоком IDEF0), выражаемые глаголом (или глагольной фразой), который описывает то, что должно быть выполнено (совершено, закончено).
Отличие определения функции в стандарте IDEF0 от стандартного определения функции в ФСА - не отмечено, что функция - это обязательно ИЗМЕНЕНИЕ объекта функции. Ну, и что в функции всегда в наличии 3 элемента: носитель функции, действие и объект функции.
Отсюда, IMHO, и неудачи в формулировании функции при использовании стандарта IDEF0, и естественная нелюбовь...
Но отход от формального определения и ратование за более "творческое" (некомпьютерное) определение функции ведет к тому, что ТРИЗ+ФСА так никогда и не станет точной наукой. Цитаты здесь не принимаются в качестве доказательства, но все же: «Наука – это та часть наших знаний, которую мы сумели понять настолько хорошо, что можем обучить этому компьютер. Там, где мы еще не достигли такого уровня понимания, речь пока идет лишь о профессиональном искусстве. Формальная запись алгоритма или программы ЭВМ, по существу, позволяет нам выполнить весьма полезный тест глубины наших знаний, так как переход от искусства к науке просто означает, что мы поняли, наконец, как автоматизировать данную предметную область» (Д. Кнут, 1984 г., Тьюринговская лекция Автоформализация знаний - ключевой фактор превращения Сети из гиперкниги в гипермозг http://www.wdigest.ru/autoformalization.htm)
Успехов,
AlexZ
Страницы