Итеративный цикл автор/рецензент

Опишем одну интересную и крайне полезную технику использования визуального моделирования при выявлении знаний о какой-либо предметной области через общение с экспертами (специалистами в этой предметной области). Эта техника называется цикл автор/рецензент (Reader/Author Cycle review process) и может применяться, например, при работе с диаграммами случаев использования. при работе как с UML, так и с любым другим языком визуального моделирования. Эта техника была определена в рамках методологии SADT.

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

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

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

- автор (author) модели — тот, кто ее создает;

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

- читатель (reader) — во всем похож на эксперта, но не обязан давать письменные комментарии к моделям и не несет ответственности за качество моделирования.

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

Кроме автора, эксперта и читателя в цикле "читатель/автор" имеются также следующие роли:

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

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

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

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

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

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

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

Рис. 8.3. Пример исходной, первой диаграммы.

Рис. 8.4. Пример итоговой диаграммы.

Карты памяти

Карты памяти (Mind Maps) – техника работы с различными знаниями, предложенная и развитая английским психологом Тони Бьюзеном в конце 70-х годов прошлого века. Она очень простая и используется при работе с информацией любого вида, для ее структурирования, осмысления, лучшего усвоения и запоминания. На листе бумаги, в центре, рисуется объект, обозначающий ту тему или предмет, который мы рассматриваем. Далее рисуются вторичные объекты, которые поясняют и уточняют данный и соединяются с ним дугами. И так далее. Пример представлен на рис. 8.5.

Рис. 8.5.

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

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

Рис. 8.6.

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

Рис. 8.7.

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

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

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

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

Вопросы

1. Какова роль актеров при построении диаграмм случаев использования?

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

3. Какие бывают виды актеров?

4. Расскажите о бизнес-диаграммах случаев использования.

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

6. Расскажите о разных вариантах применения диаграмм случаев использования.

7. Расскажите о применении случаев использования в управлении разработкой.

8. Расскажите об основной идее цикла автор/рецензент.

9. Как этот цикл можно использовать при извлечении знаний из эксперта? Расскажите о дополнительных особенностях этого процесса. Примерьте эту технику для собственного использования и поделитесь возникшими соображениями.

10. Расскажите об истории карт памяти, а также о том, что это такое.

11. Перечислите и кратко охарактеризуйте основные направления по практическому использованию карт памяти. Как именно вы используйте карты памяти? Собираетесь ли вы их использовать?

12. Расскажите о продукте Comapping и его основных возможностях по работе с картами памяти.