4.5. Другие атрибуты качества системы

Итак, мы провели обобщенный анализ атрибутов качества. В классификациях атрибутов, исследовательской литературе и учебниках по программной инженерии упоминается ряд других атрибутов, которые частично отражены в наших сценариях. К примеру, во многих случаях существенное значение имеет масштабируемость (scalability); в нашем обзоре этот атрибут качества учитывается как модификация мощности системы — количества пользователей, которые могут работать в ней одновременно. Переносимость (portability) представлена как изменение платформы.

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

4.6. Коммерческие атрибуты качества

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

♦ Срок выхода продукта на рынок. При наличии серьезной конкуренции, а также при условии ограниченности времени, в течение которого система или продукт имеют шансы на успех, существенное значение приобретает продолжительность разработки. Это, в свою очередь, приводит к потребности в приобретении или повторном использовании существующих элементов.

Для сокращения сроков выхода продукта на рынок часто используются готовые элементы наподобие коммерческих коробочных продуктов (сот- mercial off-the-shelf products, COTS) или элементы из предшествующих проектов. Возможность вставки или размещения в данной системе подмножества сторонней системы зависит от декомпозиции системы на элементы.

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

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

♦ Целевой сегмент рынка. Если речь идет об универсальном (массовом) программном обеспечении, потенциальный объем рынка определятся набором платформ и функций. Таким образом, чем больше внимания уделяется переносимости и функциональности, тем больше доля рынка. Определенную роль в этом контексте играют и другие атрибуты качества — в частности, производительность, надежность и практичность. В случаях, когда компания планирует выйти на масштабный рынок с рядом родственных продуктов, лучше всего подходит стратегия линейки продуктов с общим для всех систем ядром (которое, кстати, зачастую обеспечивает переносимость), вокруг которого строятся разные программные уровни — чем дальше, тем специфичнее. Методика построения линеек программных продуктов рассматривается в главе 14.

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

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