«Привет, Фил, это снова Мария. У меня вопрос о новой служебной системе, которой вы сейчас занимаетесь. Как вы знаете, эта система работает на нашем мэйнфрейме и каждый отдел должен ежемесячно оплачивать используемое дисковое пространство и загрузку процессора. Похоже, что в новой системе файлы занимают в два раза больше места на диске, чем в старой. Что еще хуже, загрузка процессора за сессию в три раза выше, чем обычно. Вы можете объяснить мне, что происходит?»
«Конечно, Мария. Вспомните, вы хотели, чтобы в этой системе хранилось больше данных о каждом сотруднике, чем в предыдущей, поэтому, естественно, база данных стала значительно больше. Следовательно, ваша ежемесячная плата за использование дискового пространства выросла. Кроме того, вы и остальные сторонники продукта просили, чтобы с новой системой было удобнее работать, для чего мы сконструировали этот замечательный графический интерфейс. Однако при этом процессору требуется намного больше компьютерной мощности, чем в предыдущей системе с текстовым режимом отображения. Вот почему так возросла загрузка процессора. Но ведь с новой системой намного удобнее работать, не так ли?»
«Так-то оно так, но я и представить себе не могла, что ее работа будет обходиться так дорого. У меня из-за этого могут быть неприятности. Мой менеджер нервничает. При таких условиях он уже в апреле израсходует годовой бюджет, выделенный отделу на компьютерные нужды. Не могли бы вы исправить систему, чтобы снизить стоимость ее работы?» Фил расстроился. «Ничего исправлять не нужно. Новая система учета сотрудников — это именно то, что вы заказывали. Я предполагал, вы отдаете себе отчета том, что если вы храните больше данных или больше работаете на компьютере, то ваши затраты вырастут. Возможно, нам следовало обсудить это раньше, поскольку сейчас уже практически ничего не удастся сделать. Мне очень жаль».
Естественно, что пользователей, как правило, интересуют функциональные или поведенческие требования — то есть возможности, предоставляемые ПО, однако для успеха ПО недостаточно правильно реализовать соответствующую функциональность. Кроме того, пользователей волнует, насколько хорошоновая система будет работать. К характеристикам, описывающим это свойство системы, относятся легкость использования, быстрота запуска, количество сбоев и обработка неожиданных ситуаций. В целом они называются атрибутами качества ПО или факторами качества исчитаются частью нефункциональных (или не поведенческих) требований к системе.
Довольно трудно дать определение атрибутам качества, однако часто именно они отличают продукт, которые просто работает так, как ожидалось, от продукта, который вызывает у клиентов восхищение. По мнению Роберта Шаррета (Robert Charette, 1990), «В реальных системах успех или неудачу проекта часто определяют именно нефункциональные требования, а не функциональные». В отличном ПО выдержан оптимальный баланс конкурирующих характеристик качества. Если в ходе сбора информации о требованиях вы досконально не выясните ожидания клиента, относящиеся к качеству, то вам крупно повезет, если продукт их удовлетворит. Но, как правило, более частый исход — разочарованные пользователи и расстроенные разработчики.
С технической точки зрения атрибуты качества влияют на важные решения, касающиеся архитектуры и проектирования; примером может служить распределение системных функций по различным компьютерам для достижения целей, связанных с производительностью или целостностью. Гораздо труднее и дороже перестраивать систему, чем спланировать необходимые параметры с самого начала.
Клиенты, как правило, высказывают свои ожидания о качестве продукта неявно, однако все же в ходе сбора информации удается выяснить основное. Хитрость заключается в том, чтобы уловить, что же стоит за их рассуждениями о том, что система должна быть простой в обращении, быстрой, надежной или устойчивой к сбоям. Качество, во всех его проявлениях, должно быть определено и клиентами, и теми, кто создает, тестирует и поддерживает ПО. Вопросы, с помощью которых выясняются невысказанные ожидания клиентов, позволяют установить и качество продукта, и критерии проектирования, что поможет разработчикам создать отличный продукт.
Атрибуты качества
К атрибутам качества можно отнести несколько дюжин характеристик продукта (Charette, 1990), хотя для большинства проектов хватило бы всего нескольких. Если разработчикам известно, какие характеристики наиболее важны для успеха проекта, они могут выбрать соответствующие приемы, работая над архитектурой, проектированием и реализацией ПО, которые позволят достичь определенного качества (Glass, 1992; DeGrace и Stahl, 1993). Для классификации атрибутов качества применяются различные схемы (Boehm, Brown и Lipow, 1976; Cavano и McCall, 1978; IEEE 1992; DeGrace и Stahi, 1993). Один из способов классификации основан на разделении характеристик, которые проявляются в период выполнения, и тех, что не проявляются (Bass, Clements и Kazman, 1998). Согласно другому способу разделяются очевидные характеристики, главным образом важные для пользователей, от скрытых качеств, которые имеют значение для службы технической поддержки. Последние косвенно влияют на мнение клиента, так как упрощают возможные изменения продукта, его корректировку, проверку и переход на другие платформы.
В табл. 12-1 перечислено несколько атрибутов качества обеих категорий, которые необходимо принимать во внимание в любом проекте. Некоторые много значат для встроенных систем (эффективность и надежность), тогда как другие особенно важны для Интернет-приложений и приложений для мэйнфреймов (доступность, целостность и легкость в эксплуатации) или для настольных систем (способность к взаимодействию и удобство и простота использования). Для встроенных систем часто учитывают и другие важные атрибуты качества, например безопасность (о которой рассказывалось в главе 10), легкость и простота установки и обслуживания. Для Интернет-приложений также важен еще один атрибут — масштабируемость.
В идеальном мире каждая система имела бы максимально возможные значения всех этих атрибутов. Она была бы постоянно доступна и интуитивно понятна, не испытывала бы никаких сбоев, моментально предоставляла бы результаты, естественно, всегда корректные. Поскольку все перечисленное — утопия, советую вам выяснить с помо щью табл. 12-1, какие атрибуты наиболее важны для успеха вашего проекта. Затем разделите их на те, что важны пользователям, и те, что важны разработчикам, чтобы дизайнеры смогли принять соответствующие решения.
Таблица 12-1. Атрибуты качества ПО
| Важны преимущественно для пользователей | Важны преимущественно для разработчиков |
| Доступность Эффективность Гибкость Целостность Способность к взаимодействию Надежность Устойчивость к сбоям Удобство и простота использования | Легкость в эксплуатации Легкость перемещения Возможность повторного использования Тестируемость |
Для различных элементов ПО необходимы различные сочетания атрибутов качества. Для одних крайне важна эффективность, а для других — практичность. Выделите параметры качества, относящиеся к продукту в целом, и те, что важны только для определенных компонентов, классов пользователей или вариантов использования. Документируйте ваши глобальные пожелания, касающиеся качества продукта, в разделе 4.5 шаблона спецификации о требованиях к ПО, приведенного в главе 10, и ассоциируйте их с отдельными возможностями, вариантами использования или функциональными требованиями.