воскресенье, 21 августа 2011 г.

Атрибуты качества программного обеспечения


Про атрибуты качества рассказывалось здесь. Если рассмотреть эту группу более внимательно, то можно выделить основные группы:
  • runtime - это атрибуты, относящиеся ко времени работы приложения или системы; 
  • design определяет ключевые аспекты проектирования приложения или системы.

В общем случае, каждая из групп влияет на другую. Рассмотрим их подробнее. 

Группа runtime. Иначе говоря, требования из этой группы возникают на этапе проектирования и решения, принимаемые по этой группе очень трудно и дорого менять. 
Надежность - требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики).
Доступность - атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
Требования к времени хранения данных  Чтобы определить этот параметр, указывают продолжительность хранения данных. При этом, надо иметь в виду, что требования по времени хранения бывают двух видов:
  • хранить всегда пока проект существует. Например, данные пользователя. 
  • хранить ограниченное время. Например, результаты какого-либо запроса пользователя можно хранить только во время сессии. 
Гибкость/Масштабируемость - требования к горизонтальному и/или вертикальному масштабированию приложения или системы.К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные системы, поддержка большого объема памяти и файлов. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации.
Вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы.
Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
Требования к безопасности (целостность проекта),  включают в себя три большие категории: 
  • требования, связанные с разграничением доступа, 
  • требования, связанные с работой с приватными данным,  
  • требования, направленные на снижение рисков от внешних атак
Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
Требования к производительности решения,  иначе говоря, эффективность решения определяется в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи. А также ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи.

Группа design time или требования, которые могут быть изменены в процессе разработки или эксплуатации
Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). Такие требования возникают там, где общие компоненты используются несколькими модулями разрабатываемой системы.
Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований. Сильно пересекается с требованиями масштабируемости проекта.
Требования к переносимости (Portability) приложения или системы на другие платформы.
Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Это возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных
Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, например, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы
Требования к совместимости между версиями приложений, между различными приложениями и внешними подсистемами (Compatibility) определяют предыдущие версии продукта или системы, а также список версий внешнего ПО, с которыми должны быть совместимы разрабатываемый продукт или система.




При подготовке этой статьи использовались следующие материалы:
Карл Вигерс. Разработка требований к ПО.