Принципы и приемы оперирования требованиями (продолжение)

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

Прием 8. Использование метафор

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

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

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

Эта процедура становится целенаправленной и получает реальные ориентиры, если разработчики будут следовать заранее продуманной метафоре^{1В буквальном переводе с греческого "метафора" означает "перенос", что применительно к программированию следует трактовать как перенос на разрабатываемую операционную среду свойств автоматизируемой деятельности} , которая должна быть воплощена в системе. Для каждого элемента автоматизируемой деятельности должны быть найдены соответствующие образы среди средств системы (функциональная и реализационная полнота) и заданы адекватные формы (интерфейсная полнота).

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

• Точность метафоры — отражение в метафоре целей, ресурсов, средств и методов как элементов пользовательской деятельности (см. лекцию 4), рассматриваемой в качестве прототипа, и явное воплощение их в виде функций, структур данных и в поведении конструируемой программной системы. Принцип точности указывает на то, что метафора должна отражать аспекты деятельности точно так же, как они представлены в прототипе. Нарушение его ведет к ошибкам пользовательского восприятия предлагаемых средств.
• Полнота метафоры. Требуется, чтобы в метафоре в той или иной форме отражались все элементы деятельности-прототипа. Если, в программной системе удается реализовать лишь часть операционной обстановки деятельности-прототипа, то либо используется плохая метафора, либо уровень абстракции ее представления (см. следующий принцип) не выдержан. Нарушение принципа ведет к тому, что у пользователя может возникнуть ощущение дискомфорта от неоправдавшихся ожиданий и выбранному уровню абстракции.
• Единый   уровень абстракции   в представлении   метафоры. Этот принцип расшифровывается как требование представлять все элементы метафоры на одном абстрактном уровне. Нельзя выделять и частично детализировать какой-то один аспект деятельности-прототипа только по той причине, что его легко реализовать, оставив в стороне другие аспекты. Если так поступать, опять-таки возникает дискомфорт из-за напрасных ожиданий. Скорее всего, в этой ситуации не продуман уровень допустимой детализации представления.
• Структурность   метафоры. Целесообразно строить не отдельную метафору, а их систему, соответствующую структуре пользовательской деятельности. Нарушение этого соответствия неизбежно приведет к нарушению первого принципа на каком-то из уровней. В то же время структурность не означает буквальную детализацию. Напротив, необходимо ограничиваться тем уровнем отражения пользовательской деятельности, который отвечает задаче конструируемой системы.
• Использование существующих   метафор. Не следует отказываться от метафор, представленных в имеющемся программном обеспечении, и в первую очередь в программах, которые заимствуются конструируемой системой. Не следует также нарушать сложившуюся на предыдущих итерациях систему метафор. В обоих случаях новая метафора вступает в противоречие с пониманием системы, стихийно или осознанно формируемым у пользователя. Этот принцип связан с предыдущим, поскольку существующие метафоры нужно рассматривать как базовый уровень, который нельзя переступать. В противном случае будет нарушаться последующий принцип.
• Привычность и естественность метафоры. Она всегда должна быть узнаваема тем, для кого предлагается то или иное средство. Тогда становятся излишними вопросы, зачем нужно это средство, — ему всегда должно быть место среди атрибутов деятельности-прототипа. Понятно, что привычность и естественность — качества субъективные, они всегда относительны, и выяснение их в конкретной ситуации может быть затруднительным. Тем не менее, если оценить затраты на переучивание пользователей, станет понятно, что нарушение привычности и естественности обходится слишком дорого.
• Учет психологических и эргономических особенностей. Это не отдельный принцип, а комплекс рекомендаций, которые в большей мере, чем все остальное, относятся к интерфейсу создаваемой системы. Специальный разбор интерфейсных рекомендаций можно найти в работе [21]. В рамках тематики обсуждения укажем лишь на так называемый эффект первого впечатления, который имеет серьезные последствия для всех аспектов проекта. Речь идет о способности помнить первые ощущения от соприкосновения с чем-либо новым и в течение заметного времени переносить эти ощущения на последующие контакты. Применительно к метафорам это означает необходимость тщательной заботы об их выборе в самом начале проекта и реализации в первом релизе системы^{2Автор этих строк до сих пор обходит стороной одну весьма полезную возможность процессора MS Word из-за грубой ошибки в ее реализации в шестой версии, которая наверняка сегодня уже исправлена. Обходные пути кажутся более надежными.}.

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

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