... ↑
wolf_stranger в посте Openmeta (оригинал в ЖЖ)
Я, вообще-то, имел в виду софт, в котором в удобном и обозримом виде можно было бы прописать навыки, их зависимости друг от друга (см. мой коммент выше), и выбрать для любого набора навыков все, что он за собой тащит из зависимостей. НО. "Прописать навыки" не просто названиями, а как модели, пригодные для:
- инсталляции
- проверки - есть ли у человека такая модель.
с точки зрения поддержки софтом здесь много не сделаешь - но нужные поля ввести надо: внутренние критерии наличия, внешние критерии, алгоритм/стратегия, может, еще что-то...
С другой стороны - навыки должны организовываться в смысловые группы (к примеру, "изменение состояния", или "создание фокуса внимания"). Понятно, что такие группы могут пересекаться.
Это тот минимум, который пришел в голову сразу.
Кстати, в таком случае начиают происходить интересные вещи - если стратегия выписана не процессуально, как в НЛП, а по достигаемым целям - имеем сразу пучок различных вариантов - в которых стратегия одна, а методы достижения подцелей различны. Вот вам и "создание техник" нлп-мастерское...
То есть цель - создать софт поддержки репозитория - и как естественно вытекающее следствие - создания дистрибутива.
Дальше его, вероятно, можно будет расширить играми/упражнениями (в смысле - компьютерными) для установки навыков.
5 комментариев
сначала старые сначала новые
А может, есть что-то такое? Задачка-то довольно распространенная, по идее - описать набор базовых блоков и то, как из них собирается что-то большее...
Т.е. "для себя" здесь вторично. первична - возможность коллективного наполнения этого репозитория.
Ну, я вас правильно понял. Только я использовал в своем комменте другие слова. Так, выписывание стратегии по достигаемым целям -- это как раз функциональное описание по Jan Dietz, а "процессуальное" -- конструктивное описание. И так далее: пройдитесь по рекомендованным мной ссылкам.
Софт при таком подходе сводится к обычному софту представления знаний. Я склоняюсь сейчас к использованию языка представления знаний Gellish, хотя специализированный софт для него (увы!) пока доступен только коммерческий. Впрочем, хранить знания на Gellish можно в электронных таблицах, или в базах данных -- там табличный формат представления данных. Опять же, пройдитесь по ссылкам ;)
Софт при таком подходе сводится к обычному софту представления знаний. Я склоняюсь сейчас к использованию языка представления знаний Gellish, хотя специализированный софт для него (увы!) пока доступен только коммерческий. Впрочем, хранить знания на Gellish можно в электронных таблицах, или в базах данных -- там табличный формат представления данных. Опять же, пройдитесь по ссылкам ;)
Конечно, есть. Задача неоднократно встречалась при создании САПР, в которых нужно собрать что-то огромное (скажем, собрать виртуальную модель самолета из мельчайших винтиков, или нефтяной платформы из отдельных трубопроводов, или электростанции -- и совместить при этом знания электриков, материаловедов, бизнесменов, логистиков, проектировщиков, пользователей и т.д.).
Ага. Со всеми вытекающими задачами отслеживания рассогласований. Т.е. операциями commit и отслеживанием версий.
Другая формулировка для той же проблемы -- это "технологическая платформа" против "конкретного продукта". Технологическая платформа -- это все, что бывает. А в конкретный продукт (вариант) входит только то, что нужно и взаимосогласовано. И тут уже не только нужно управление версиями продукта, но и управление вариантами (продуктами) в рамках технологической платформы.
В репозитории (сосуде, СУБД), вестимо, бултыхаются и технологическая платформа, и конкретные продукты (содержание, знание).
Я тут писал для этого случая привязку к концепции жизненных циклов: http://ailev.livejournal.com/626229.html. Только слова подставьте про НЛП, ЭГ и т.д.
Другая формулировка для той же проблемы -- это "технологическая платформа" против "конкретного продукта". Технологическая платформа -- это все, что бывает. А в конкретный продукт (вариант) входит только то, что нужно и взаимосогласовано. И тут уже не только нужно управление версиями продукта, но и управление вариантами (продуктами) в рамках технологической платформы.
В репозитории (сосуде, СУБД), вестимо, бултыхаются и технологическая платформа, и конкретные продукты (содержание, знание).
Я тут писал для этого случая привязку к концепции жизненных циклов: http://ailev.livejournal.com/626229.html. Только слова подставьте про НЛП, ЭГ и т.д.