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

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

В разработке программного обеспечения измерения играют и стратегическую роль — с точки зрения бизнеса. Цифры обладают таким влиянием, которое может отсутствовать в простых словах — особенно сейчас, когда ценность слов была уменьшена многолетними безосновательными утверждениями и пустыми обещаниями. В условиях жесткой конкуренции, сокращения расходов и отсева разработчики программного обеспечения и прикладных программ все чаще вынуждены оправдывать свое существование, причем с приведением весомых аргументов. Измерения позволяют сравнить производительность с индустриальными стандартами и наилучшими достижениями. Измерения позволяют документировать постепенные улучшения производительности и качества работы. Измерения позволяют продемонстрировать конкурентное преимущество внутреннего знания или внешней независимости. Руководителям бизнеса мало что говорит более красноречиво, чем цифры. Легко заявлять о простоте использования и повышенном удобстве программного обеспечения, однако количественные сравнения могут сделать эти утверждения более убедительными. Сокращение избыточности данных на 37 % и повышение производительности транзакций на 28 % может быть наиболее убедительным аргументом в поддержку нового продукта.

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

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

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

На практике в качестве меры можно выбрать количество шагов-действий пользователя. Можно просто сравнивать количество шагов, за которое пользователь «проходит» пользовательскую ситуацию с помощью данного проекта пользовательского интерфейса, и количество шагов в сущностной пользовательской ситуации. Перевод соотношения этих чисел в проценты дает показатель сущностной эффективности данного проекта. Чем выше сущностная эффективность, тем проще пользовательский интерфейс и тем больше пользователь может рассчитывать на быстрое и эффективное решение задачи с его помощью. Этот параметр дает нам в некотором смысле абсолютную меру качества. Например, если наш первый проект дает 98 % сущностной эффективности, это означает, что дальнейшая доработка интерфейса не приведет к его значительному улучшению.

Пользовательские интерфейсы должны упорядочивать различные визуальные объекты на экранах и в диалоговых окнах. В хороших интерфей-сах организация визуальных объектов соответствует задачам, выполняемым пользователями. Как говорит специалист по пользовательским интерфейсам Алан Купер (Alan Cooper), экраны, окна и диалоговые элементы подобны разным комнатам (Cooper, 1995 [31]). Большинство людей предпочитает выполнить всю задачу в одной комнате, не переходя в другие в поисках необходимых инструментов и материалов. Они не делят работу на части, выполняемые в разных комнатах. Каждый раз, когда программное обеспечение вынуждает пользователей менять контекст взаимодействия, переключать экраны или переходить к другому диалоговому окну, ход их мыслей и работа прерываются. С каждым таким прерыванием пользователи не только работают все медленнее, но и делают больше ошибок. Хороший пользовательский интерфейс позволяет «пройти» пользовательскую ситуацию с меньшим количеством изменений контекста взаимодействия — с точки зрения общей сложности данной пользовательской ситуации. Поскольку в таких интерфейсах необходимые данные и функции объединены, эти интерфейсы не только проще применять, но и (в первую очередь) легче изучить.

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