19 ноябрь 2017
Либертариум Либертариум

Как сделать модель полезной пользователю?

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

picture

Учебный курс обычно состоит из двух составных частей:

Постоянная часть:

  • Интерфейс
  • учебно-справочное пособие по интерфейсу
  • ситуации (задачи по интерфейсу)
  • методику преподавания (создание положительной мотивации на обучение) по интерфейсу.

Предметная часть (разработка которой осуществляется отдельно для каждой предметной области и модели):

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

1. Кто создает модель?

Коллектив специалистов, создающих Модель, называется ГРУППОЙ. В Группе обычно от 2 до 6 специалистов, которые занимают различные профессиональные ПОЗИЦИИ (мы их будем именовать с прописной буквы). Для создания Модели в Группе должны быть представлены следующие позиции:

  • Программист
  • Эксперт
  • Когнитолог (специалист по представлению знаний)
  • Писатель
  • Методист.

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

Программист является профессионалом в области создания работающих программ, он проектирует и пишет текст программы Модели (так называемую РЕАЛИЗАЦИЮ).

Эксперт является авторитетом в ПРЕДМЕТНОЙ ОБЛАСТИ, для которой создается Модель.

Когнитолог работает с понятийной структурой предметной области и интерфейса, служит переводчиком между Программистом, Экспертом и другими людьми.

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

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

2. Как создают модель?

Модель создается в 3 этапа, на каждом из которых свой лидер разработки. Лидер определяется тем, что он знает ТЕХНОЛОГИЮ работы на соответствующем этапе. Тот, кто знает технологию, говорит, что и как делать, а остальные ему помогают.

              Этап                  Лидер (технолог)
           программирование      Программист
           понятизация           Когнитолог
           оформление            Писатель, Методист

2.1. Программирование

Этап ПРОГРАММИРОВАНИЯ практически совпадает по способу и технике выполнения с традиционным пониманием. Мы считаем применимым к этапу программирования весь известный опыт создателей программных продуктов, неоднократно описанный в литературе. Не будем поэтому останавливаться на описании подробностей данного процесса.

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

В результате программирования должен быть получен ПОЛУФАБРИКАТ - работающая РЕАЛИЗАЦИЯ Модели.

Дополнительно полуфабрикат может включать некоторое количество ДОКУМЕНТАЦИИ, подготовленной его создателями.

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

Традиционная технология программирования на этом переходит к этапу сопровождения. Наша же технология требует передачи полученного полуфабриката на этап ПОНЯТИЗАЦИИ.

2.2. Понятизация

Слово "ПОНЯТИЗАЦИЯ", давшее название этапу, должно напоминать о двух моментах: построении понятийного аппарата Модели и обеспечении понимания.

Лидером (технологом) на данном этапе становится Когнитолог -- в конце концов, речь идет о представлении знаний.

Понятизация идет в два приема: на первом шаге профодят РЕФЕРЕНЦИАЛЬНЫЙ АНАЛИЗ, на втором шаге -- находят аналогии и получают ГЛОССАРИЙ Модели.

На этапе референциального анализа Группа фиксирует ПОНЯТИЯ, которые были ИСПОЛЬЗОВАНЫ при программировании и описании полуфабриката Модели. Источниками при этом являются:

  • документация
  • обсуждение Модели и ее реализации
  • сообщения реализации модели, комментарии текста программы.

Понятия фиксируются в виде списка референций (ссылок, упоминаний) объектов Модели, обычно оформляемого в виде списка слов, словосочетаний и выражений. Основным требованием, предъявляемым к списку, является его полнота: фиксации подлежат все синонимы, жаргонные выражения и т.д.

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

2.3. Оформление

На этапе оформления Модели на основе глоссария и аналогий осуществляются следующие процессы:

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

3.Технология понятизации

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

На этапе понятизации Когнитолог при помощи Эксперта и Программиста должен обеспечить нахождение АНАЛОГИЙ для облегчения понимания Модели и создание ГЛОССАРИЯ Модели, содержащего термины для выражения знания о Модели.

Первое, что должно быть сделано -- это фиксация ПОНЯТИЙ, которые явно или неявно БЫЛИ ИСПОЛЬЗОВАНЫ при программировании и описании Модели и интерфейса. Причем фиксируются не понятия (это идеальные объекты), а РЕФЕРЕНЦИИ (ссылки, упоминания) на эти понятия: слова, термины, выражения, описания объектов и т.п. Считается, что данные референции соответствуют важным для выражения знаний о Модели понятиям, но на этом шаге не делается предположений о том, каким термином мы будем называть это понятие -- таковые термины будут найдены на втором шаге и составят ГЛОССАРИЙ.

Выполнять шаг фиксации наиболее просто в том случае, когда существует ДОКУМЕНТАЦИЯ, полученная Программистом и Экспертом на этапе программирования. Эта документация часто представляет собой литературу типа "поток сознания": Программист описывает свою РЕАЛИЗАЦИЮ Модели, не выбирая способов референции понятий Модели, нещадно путая понятия собственно предметной области и структур данных, примененных в реализации, тесно переплетая "программистские заморочки" с жаргонизмами, услышанными от Эксперта. В такой документации мы можем услышать про "кольцевой буфер траекторий частиц", "двусвязный список списков параметров специфицированных запросов" и т.д. Такая документация обычно полностью удовлетворяет других Программистов, но неоправданно сложна для любых других Пользователей, включая даже других Экспертов.

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

Заметим, что нас интересует более глубокий процесс, чем процесс составления "предметного указателя", "индекса" -- нас интересуют не только ЯВНО присутствующие в тексте термины, но и "замаскированные" референции -- те, которые могут не осознаваться авторами текста как ссылки на понятия. Иными словами, фиксировать надо не ОПРЕДЕЛЕНИЕ, а ИСПОЛЬЗОВАНИЕ понятий.

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

         частица             запрос
         траектория          специфицированный запрос
         кольцевой буфер     параметр запроса
                             список параметров запроса
                             двусвязный список

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

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

Если в тексте для референции (указания) одного объекта приводятся синонимы -- их надо фиксировать в одной строчке списка через "/".

Как искать референции на понятия? Явно упомянутые термины находить легче всего. Для некоторых понятий документация содержит определение называющих их терминов, другие понятия обнаруживают себя по употреблению слов, не принадлежащих общенаучной лексике (необязательно существительных!).

Признаками референции на не имеющее своего термина, но важное понятие являются "ПОВТОРИЗМЫ": в тексте часто повторяется какой-либо оборот, может даже целое предложение. Каждый такой оборот должен вызвать подозрение на "РАЗВЕРТКУ" пропущенного термина (употребление вместо термина его развернутого определения). Если Вы встретили в тексте несколько раз выражение "тот, кто ведает мед", то его целесообразно зафиксировать в списке. "СВЕРТКУ" же в слово "медведь" можно провести на следующем шаге - шаге составления глоссария.

Но документация существует не всегда и она, как правило, не содержит референции на все необходимые для объяснений и коммуникации по поводу Модели понятия.

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

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

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

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

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

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

Составление глоссария (перевод с языка разработчиков Модели на язык Пользователя) ведется по группам понятий. Группы выделяются интуитивно на основе списка референций. Для каждой группы выполняются следующие два шага:

  1. С использованием списка референций как основы, ищутся аналогии из обыденной (непрофессиональной) жизни и культуры, на примере которых легко можно объяснить сущность и взаимосвязь группы понятий. (ВНИМАНИЕ! Понимание Модели полностью зависит от качества аналогий.)
  2. После нахождения аналогии соответствующие понятия из списка именуются подходящим термином. При этом часто не только изменяется лексика (слова) референции, но также убираются избыточные и добавляются необходимые новые понятия.

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

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

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

При переводе получается некоторый "приварок": продвижение в ДЕМИСТИФИКАЦИИ (облегчении понимания) предмета за счет улучшения его понятийного аппарата и упрощения лексики. Это безусловно разрушает кастовые профессиональные границы и вызывает негодование у большинства Экспертов. (Гипотеза методологов: сложная терминология профессионалов, запутанные представления нужны им для осознания собственной значимости и особенности как некоторой избранной касты. И только тот, кто за несколько лет овладеет всей заумью неудобной терминологии, будет допущен к профессиональному общению).

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

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

Тем не менее, понятизация предлагает следующий принцип: выбирается самый простой из существующих вариант терминологии предмета, который тщательно структурируется и может даже быть слегка переделан. ПОНИМАНИЕ имеет приоритет перед ТОЧНОСТЬЮ ПРОФЕССИОНАЛЬНОЙ ТЕРМИНОЛОГИИ, ибо учим ПРОФЕССИОНАЛЬНОМУ МЫШЛЕНИЮ, а не СУЩЕСТВУЮЩЕЙ ПРОФЕССИОНАЛЬНОЙ КОММУНИКАЦИИ.

Некоторые замечания для выбора терминов

  • Из синонимов выбирайте русский и непрофессиональный вариант (например, вместо ДЕБИТ и КРЕДИТ лучше ПРИХОД и РАСХОД). Если аналогов нет (например, ПИКСЕЛ),то термин может остаться.
  • Используйте термины из наиболее распространенного стандарта (например, в КАРТОЧКЕ находятся ГРАФЫ, а не ПОЛЯ/РЕКВИЗИТЫ/СЛОТЫ -- таков ГОСТ, и этому учат всех секретарей-машинисток).
  • Останавливайтесь в подборе вариантов только тогда, когда есть ощущение "законченности", "правильности". Обычно средняя скорость перевода -- 4--5 понятий в день.
  • Никогда не применяйте "профессиональные" аналогии. Аналогии должны быть взяты из "простой жизни".
    [Не считайте, что объяснить работу стека проще на примере магазина: во-первых, большинство ассоциирует магазин с торговой точкой; во-вторых, не так много людей лично "вталкивали" и "выталкивали" патроны в автоматическом оружии (или имели дело со "стеком" подносов в столовой).
    Гораздо проще для объяснения использовать стопку (бумаги, кирпичей, блинов), где работать можно только с верхним элементом, а операции - снять и положить. Сравнивая эти две аналогии заметим, что максимально возможное количество элементов в стеке -- емкость магазина и ??? у стопки. С текущим количеством элементов наоборот: у стопки это высота, а у магазина -- ???. В большинстве же случаев нас будет интересовать "текущее количество элементов", а не "максимально возможное количество элементов" (в конце концов, все зависит и от варианта реализации стека).
    Ряд терминов (уже термины, а не слова "из аналогии"!) СТОПКА, ВЫСОТА, ???, СНЯТЬ, ПОЛОЖИТЬ, ВЕРХНИЙ лучше рядов {СТЕК, ???, ГЛУБИНА, ВЗЯТЬ, ДОБАВИТЬ, ВЕРШИНА + аналогия "труба с запаянным концом и бочонками-элементами"}, и {МАГАЗИН, ???, ЕМКОСТЬ, ВЫТОЛКНУТЬ, ВТОЛКНУТЬ, ПОСЛЕДНИЙ + аналогия "магазин для автоматического оружия"}. Аналогия может предоставить в Ваше распоряжение названия объектов, процессов, признаков и т.д. Не бойтесь делать эти названия терминами непосредственно (используйте термин КАРТОТЕКА вместо БАЗА ДАННЫХ + объяснение, что база данных похожа на картотеку; СТОПКА вместо СТЕК + объяснение, что стек похож на стопку). Большинству Пользователей легче понять и использовать в коммуникации фразы типа "стопка заполненных карточек", а не "стек непустых записей".
    ]
  • Бойтесь многословных терминов, особенно часто встречающихся. Если термин встречается очень редко -- примените "развертку": сам термин выкиньте, а вместо него используйте развернутое определение. Если термин встречается относительно редко, допустимо использование двухсловного сочетания. Если термин встречается часто -- нужно обязательно уложиться в одно слово. Если есть понятие, но оно в списке референций представлено оборотом или предложением, то термин для него, скорее всего, надо придумать ("свертка").
    [Если есть обобщающее имя в культуре, но хочется подчеркнуть особое его понимание --попробуйте не добавлять определяющее слово (и не дай бог цепочку слов!), а уложиться все-таки в одно слово (например, добавив приставку или суффикс (код и псевдокод, диск и дискета), используя написание с прописной буквы (модель и Модель, сопротивление и Сопротивление), составив двухкоренное слово (онтологическая операция -- онтоп), заменив обратным понятием (сопротивление -- проводимость) и т.п.).]
  • Не бойтесь придумать новое слово, но стремитесь, чтобы оно не звучало как "грршп" или "оожаа". Слово должно быть склоняемо и походить на естественное, а не искусственное рыбсырснабсбыт. В часто употребляемых словах избегайте звуков Ц, Ф.
  • Если попадаются куски текста, сплошь забитые часто повторяющейся терминологией -- надо придумывать нотацию, способ записи, синтаксис (типа химической номенклатуры, языков программирования, фейнмановских диаграмм и т.д.) Этот способ записи должен удовлетворять требованию скорописи: скорость проговаривания содержания записанного должна быть сравнима со скоростью записи.
  • В глоссарий должны попадать не глаголы, а отглагольные существительные, обозначающие процесс.
  • Используйте словари. Особенно полезно смотреть слова по следующей цепочке: подобрать синонимы, затем все их перевести на английский и посмотреть у каждого слова английские синонимы, затем перевести назад на русский и посмотреть на получившийся список слов. Часто анализ этого списка выводит на хорошую идею. Например, "выходной поток" -- "листинг" -- "распечатка".
  • Обязательно "поиграйтесь" с каждым найденным термином: попридумывайте фразы с его использованием. Мы называем этот прием "словоупотребление". Если эти фразы звучат плохо (говорим -- "не словоупотребляется") -- значит вы на ложном пути. Если удалось придумать только фразы, являющиеся разнообразными определениями придуманного термина -- немедленно выкиньте этот термин, тут наверняка нужно применить "развертку".
  • Если при обсуждении термина всплывают термины-кальки, то попробуйте все-таки перевести кальку. Часто при этом появляются неплохие идеи.
  • Хорошая аналогия объясняет группу терминов (4--7 терминов). Если каждый термин требует своей аналогии, то тут что-то не так. Если термин есть, а аналогии нет, то тут тоже что-то не так.
  • Лучше проводить работу в режиме "погружения" -- многочасовые ежедневные обсуждения. Это нужно прежде всего для того, чтобы не терять навыка использования новых терминов в продолжении обсуждений. Если допустить перерыв, то новая лексика мгновенно забывается, прорывается старая и мешает работе -- трудно обеспечить концептуальное единство терминологии.
liberty@ice.ru Московский Либертариум, 1994-2017