В этом разделе описываются атрибуты качества, которые в первую очередь важны для разработчиков ПО и специалистов по техническому обслуживанию.
Легкость в эксплуатации. Этот атрибут показывает, насколько удобно исправлять ошибки или модифицировать ПО. Легкость в эксплуатации зависит от того, насколько просто разобраться в работе ПО, изменять его и тестировать, и тесно связано с гибкостью и тестируемостью. Этот показатель крайне важен для продуктов, которые подвергаются частым изменениям, и тех, что создаются быстро (и, возможно, с экономией на качестве). Легкость в эксплуатации измеряют, используя такие термины, как среднее время, требуемое для разрешения проблемы, и процент корректных исправлений. Для Chemical Tracking System одно из требований к легкости в эксплуатации сформулировано таким образом:
Легкость в эксплуатации-1 Программист, занимающийся техническим обслуживанием ПО, должен модифицировать существующие отчеты, чтобы привести их в соответствие с изменениями в положениях федерального правительства в области химии, затратив на разработку не более 20 рабочих часов.
При работе над проектом Graphics Engine мы понимали, что нам придется часто вносить исправления в ПО, чтобы оно соответствовало потребностям пользователей. Мы указали примерно такие критерии, чтобы разработчикам удалось создать ПО, более легкое в эксплуатации:
Легкость в эксплуатации-2. Вложенность вызываемых функций не должна превышать два уровня.
Легкость в эксплуатации-3. Для каждого программного модуля непустые комментарии в соотношении к исходному коду должны составлять как минимум 0,5.
Ставьте такие задачи разработчикам осторожно, иначе те, лишившись самообладания, начнут действовать формально, выполняя букву, но не суть задачи. Поработайте с программистами, занимающимися техническим обслуживанием, чтобы понять, какие качества исходного кода облегчат им внесение изменений или исправление недостатков.
|
|
Для аппаратных устройств со встроенным ПО часто имеются требования к легкости в эксплуатации. Одни из них относятся к выбору проектирования ПО, в то время как другие влияют на проектирование оборудования. Например последнее можно сформулировать так:
Легкость в эксплуатацин-4. Проектирование принтера позволяет сертифицированному ремонтнику заменить кабельный шнур печатающей головки не более чем за 10 минут, датчик ленты не более чем за 5 минут и привод ленты не более чем за 5 минут.
Легкость перемещения. Мерой ее измерения можно считать усилия, необходимые для перемещения ПО из одной операционной среды в другую. Некоторые практики считают возможность интернационализации и локализации продукта высшей степенью его мобильности. Приемы разработки ПО, которые делают легким его перемещение очень схожи с теми, что применяют, чтобы сделать ПО многократного используемым (Glass, 1992). Обычно мобильность продукта или не имеет никакого значения, или крайне важна для успеха проекта. Важно определить те части продукта, которые необходимо легко перемещать в другие среды, и описать эти целевые среды. Затем разработчики выберут способы разработки и кодирования, которые увеличат мобильность продукта.
Например, одни компиляторы определяют размер типа данных integer в 16 бит, а другие — 32 бит. Чтобы выполнить требования к мобильности, программисту надо в символической форме определить тип данных WORD как 16-битное целое без знака и использовать тип данных WORD вместо целочисленного типа данных, принятого в компиляторе по умолчанию. Таким образом гарантируется, что все компиляторы будут одинаково обращаться к элементам данных типа WORD, что сделает работу системы предсказуемой в различных операционных средах.
|
|
Возможность повторного использования. Постоянная задача разработки ПО — возможность повторного использования — показывает усилия, необходимые для преобразования программных компонентов с целью их дальнейшего применения в других приложениях. Затраты на разработку ПО с возможностью повторного использования значительно выше, чем на создание компонента, который будет работать только в одном приложении. Оно должно быть модульным, хорошо задокументированным, не зависеть от конкретных приложения и операционной среды, а также обладать некоторыми универсальными возможностями. Цели многократного использования сложно количественно измерить. Укажите, какие элементы новой системы необходимо спроектировать таким образом, чтобы упростить их повторное применение, или укажите библиотеки компонентов многократного использования, которые необходимо создать дополнительно к проекту. Например:
Возможность повторного использования-1. Функции ввода химических структур должны быть спроектированы таким образом, чтобы их удавалось повторно использовать на уровне объектного кода в других приложениях, построенных с учетом международных стандартов для представления химических структур.
|
|
Тестируемость. Этот атрибут также называют проверяемостью, он показывает легкость, с которой программные компоненты или интегрированный продукт можно проверить на предмет дефектов. Такой атрибут крайне важен для продукта, в котором используются сложные алгоритмы и логика или имеются тонкие функциональные взаимосвязи. Тестируемость также важна в том случае, если продукт необходимо часто модифицировать, поскольку предполагается подвергать его частому регрессивному тестированию, чтобы выяснить, не ухудшают ли внесенные изменения существующую функциональность.
Поскольку я и команда разработчиков твердо знали, что нам придется тестировать Graphics Engine много раз в период его неоднократных усовершенствований, мы включили в спецификацию следующую директиву, касающуюся тестируемости ПО:
Тестируемость-1. Максимальная цикломатическая сложность модуля не должна превышать 20.
Цикломатическая сложность (cyclomatic complexity) — это количество логических ответвлений в модуле исходного кода (McCabe, 1982).
Чем больше ответвлений и циклов в модуле, тем тяжелее его тестировать, понимать и поддерживать. Конечно, проект не будет провален, если значение цикломатической сложности одного из модулей достигнет 24, однако наша директива указала разработчикам уровень качества, к которому следует стремиться. Если бы ее (она представлена как требование к качеству) не было, не факт, что разработчики при написании своих программ приняли бы во внимание такую характеристику, как цикломатическая сложность. В результате код программы мог оказаться так запутан, что его тщательное тестирование и дополнение оказалось бы практически невозможным, а отладка вообще стала бы кошмаром.