Хотя документация и справочные системы зачастую бывают упрощенными, они являются важными компонентами для обеспечения юзабилити систем — настолько важными, что самая большая глава в книге «Software for Use» (Constantine и Lockwood, 1999 [30]) целиком посвящена разработке справочных систем. Хорошая документация и правильно организованная, отзывчивая справочная система могут облегчить применение сложной системы; и наоборот, неадекватная, плохо организованная справочная система способна полностью испортить систему, которая во всех других отношениях разработана грамотно.

Организация документации и онлайновой помощи на основе сущностных пользовательских ситуаций — это новый и эффективный способ улучшения юзабилити программного обеспечения. Сущностные пользовательские ситуации представляют собой все возможные потребности пользователя и цели, которых можно достичь при помощи данной программы. Каждая сущностная пользовательская ситуация, написанная должным образом, является отдельной задачей, которая закончена и четко определена с точки зрения внешнего пользователя. Эта задача описана на языке пользователей с учетом данной предметной области. Вот почему сущностные пользовательские ситуации идеально подходят для организации справочной системы, ориентированной на задачи («how to…?»). При этом каждая ситуация имеет свой раздел и содержит набор инструкций для активизации данной пользовательской ситуации. Даже взаимосвязи внутри карты пользовательских ситуаций — расширение, конкретизация и объединение — могут быть уместно и естественно отображены в документации и справочной системе в виде связей и перекрестных ссылок.

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

По материалам журнала Object Magazine, июнь 1997 г.

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

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

По многим причинам руководители проектов по разработке программного обеспечения в первую очередь применяют метрику размера и сложности. То, что измеряется, является очевидным и может быть легко интерпретировано. Измерения размера и сложности позволяют отслеживать продвижение разработки и количественно оценивать продуктивность разработчиков. В сочетании с хорошей базой статистических данных такие измерения дают возможность намного точнее и надежнее оценить время разработки и связанные с ней расходы, чем это можно сделать при помощи более распространенных субъективных подходов, которые зачастую сводятся к выдумыванию ex nihilo [42] и последующему умножению на какой-нибудь взятый с потолка коэффициент.

Для разработчиков количественные измерения качества проектирования потенциально являются более важными, чем простые измерения количества кода. Проектная метрика основана на исчисляемых и измеряемых аспектах проекта, которые описывают важные стороны законченного продукта — все, что интересует разработчиков с точки зрения предполагаемого метода реализации, работы и обслуживания данного программного обеспечения. Например, компонентное сцепление и межкомпонентное связывание, два известных измеримых параметра проектирования, описывают, насколько легко можно будет модернизировать или расширить программу с помощью частичной декомпозиции на взаимосвязанные элементы. Термины «сцепление» и «связывание», впервые появившиеся в раннюю эпоху структурного проектирования (Yourdon и Constantine, 1979 [70]), со временем перешли в объектно-ориентированное проектирование в виде мер сцепления классов и межклассового связывания. Формы этих мер были широко исследованы — как классическая, так и объектно-ориентированная (Henderson-Sellers, Constantine и Graham, 1996 [39]).

В ответе на основной вопрос «лучше ли этот проект, чем тот?» измерение проектных параметров дает ряд ощутимых преимуществ для разработчиков и дизайнеров. Эти измерения позволяют сравнивать разные подходы и определять наилучшее решение, не прибегая к постановлениям руководства или бросанию летающих тарелок с 30 шагов. Уже на ранних этапах разработки они позволяют узнать, идет ли она по правильному пути и на каком повороте могут возникнуть серьезные трудности. В процессе проектирования или последовательной доработки они позволяют нам оценить, изменяется ли проект в лучшую сторону или просто изменяется. Правильные измерения, выполненные в правильный момент, могут сказать нам о том, насколько совершенным является наш проект в некотором абсолютном смысле. Является ли эта версия достаточно близкой к оптимальной или к оптимуму еще нужно проделать долгий путь? Принесут ли какую-нибудь существенную пользу дополнительные испытания или доработки?