Классификация атрибутов качества

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

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

Атрибуты, важные для пользователей

Доступность

Под доступностью понимается запланированное время доступности (up time), в течение которого система действительно доступна для использования и полностью работоспособна. Формально доступность равна среднему времени до сбоя (mean time to failure, MTTF) системы, деленному на сумму среднего времени до сбоя и ожидаемого времени до восстановления системы после сбоя. На доступность также влияют периоды планового технического обслуживания.

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

Эффективность

Эффективностью называется показатель того, насколько эффективно система использует производительность процессора, место на диске, память или полосу пропускания соединения. Если система тратит слишком много ресурсов, пользователи заметят снижение производительности – видимого показателя эффективности. Недостаточная производительность раздражает пользователей, которые ожидают вывода на экран результата запроса к базе данных. Но проблемы производительности, кроме того, ставят под удар безопасность, например, при перегрузке системы контроля процессов реального времени. Определите минимальную конфигурацию оборудования, при которой удается достичь заданных эффективности, пропускной способности и производительности.

Чтобы определить нижний предел в случае непредвиденных условий и последующий рост, вы можете воспользоваться такой формулировкой: «Как минимум 25% пропускной способности процессора и оперативной памяти, доступной приложению, не должно использоваться в условиях запланированной пиковой нагрузки». Однако типичные пользователи не формулируют требования к эффективности в таких технических терминах. Максимум, на что они способны, так это упомянуть время отклика или заполнение пространства на диске. Дело аналитика – задать вопросы, которые выявят ожидания пользователей о приемлемом снижении производительности, возможных пиках нагрузки и ожидаемом росте.

Гибкость

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

Целостность

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

Для формулирования требований к целостности следует использовать точные термины: проверка идентификации пользователя, уровни привилегий пользователя, ограничения доступа или определенные данные, которые должны быть защищены. Например: «Только пользователи, обладающие привилегиями уровня Аудитор, должны иметь возможность просматривать транзакции клиентов».

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