Глава 11 4 страница

Номер	Сценарий
	При установке системы Nightingale в больнице необходимо преобразовать существующую в ней базу данных
	В результате ошибки в процессе репликации база данных транзакций рассинхронизируется с резервной базой данных
	Системная ошибка приводит к невозможности зачисления платежей на счета, находящиеся в Аризоне
	Контрольный журнал транзакций не пополняется на протяжении трех дней (как исправить ошибку?)
	Одно из отделений меняет продолжительность рабочего дня и месяца
	Получение информации о зачислении платежа от системы управления базами данных страховой компании (при помощи определения метаданных)
	Введение нового технологического процесса входной и выходной регистрации пациентов
	Пакетные процессы инициируются на временной и событийной основах
	Неисправность главной магистрали передачи данных от информационного ядра к филиалам клиники
	Сервер базы данных одного из отделений клиники не загружается
	При составлении отчета требуется получить информацию из двух больниц, в каждой из которых используется индивидуальная конфигурация
	Центр денежных переводов дважды подает одну и ту же группу платежей, причем операции начинаются только после второй подачи
	Терапевт, специалист по реабилитации, переводится в другую больницу; при этом ему требуется доступ к историям болезни бывших пациентов с полномочиями чтения
	Согласованное распределение ряда изменений среди нескольких узлов в учреждениях здравоохранения (формы и конфигурации)
	В результате пожара в информационном центре информационное ядро приходится перевести в другое место
	Больница переуступает большое количество счетов, выставленных на другое подразделение
	Изменение правил составления предупреждений о взаимоисключающих лекарственных препаратах
	Пользователь в бухгалтерии больницы хочет перейти из режима распечатки выходных данных в режим их оперативного просмотра
	Телефонная компания меняет междугородный телефонный код
	Администратор счетов предумышленно перевел с них небольшие суммы на счета своих друзей. Как выявить нарушителя и определить масштаб злоупотреблений?

 

После того как мы провели слияние нескольких почти идентичных сценариев, заинтересованные лица проголосовали. Каждому из них мы выделили по 22 го­лоса (30 % от 72 сценариев плюс округление до ближайшего целого числа), кото­рые следовало подавать в два захода. Подсчитав голоса, мы вместе с участниками группы оценки на протяжении получаса дополняли составленное во время опе­рации 5 дерево полезности новыми высокоприоритетными сценариями, которых набралось всего около десятка. Все сценарии с высоким приоритетом, выявлен­ные в ходе операции 7, мы без лишних раздумий поместили на дерево полезно­сти в виде новых листьев существующих ветвей. Этим мы хотели показать, что представления архитектора и заинтересованных лиц о важнейших атрибутах ка­чества оказались сходными.

Разобравшись с согласованием отдельных сценариев па дереве полезности, мы приступили к анализу тех из них, которые получили наибольшее число голосов.

 

Операция 8: анализ архитектурных методик

В ходе операции 8 мы дополнительно провели анализ семи сценариев; следует заметить, что по меркам АТАМ это довольно много. Учитывая ограниченность объема книги, мы рассмотрим результаты одного-елинственного, 15-го сценария (см. соответствующую врезку).

 

Операция 9: презентация результатов

Девятая операция предполагает проведение одно- или двухчасовой презентации с изложением всех достигнутых результатов и полученных выводов. В начале презентации необходимо показать слушателям набор стандартных слайдов с ос­новными тезисами метода; кроме того, следует подготовить несколько чистых слайдов-шаблонов, на которые впоследствии нужно будет нанести сводные дан­ные по коммерческим факторам и архитектуре, перечень методик, дерево полез­ности, сведения об анализе сценариев и список результатов его проведения.

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

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

СЦЕНАРИЙ 15: ПРИ УСТАНОВКЕ СИСТЕМЫ NIGHTINGALE В БОЛЬНИЦЕ

НЕОБХОДИМО ПРЕОБРАЗОВАТЬ ЕЕ СУЩЕСТВУЮЩУЮ БАЗУ ДАННЫХ

Нет ничего удивительного в том, что проработке этого сценария архитектор уделил особое внимание — ведь от его реализации зависел успех системы в целом. Процедуру, ранее доку­ментированную, он изобразил для нас на белой доске.

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

Результаты анализа процесса миграции убедили участников группы оценки в том, что процедура тщательно продумана, ее преимущества известны, а ограничения обоснованны. Тому, что архитектор не упомянул об этом процессе во время презентации (операция 3), мы нисколько не удивились. Неожиданность заключалась в другом: в пакете документации, который мы получили и изучили еще до начала первого этапа, о нем также ничего не было сказано. В ответ на наше недоумение архитектор признал, что процедура еще не документиро­вана, тем самым предоставив нам повод зафиксировать риск. Впрочем, она компенсировалась нерискованным решением, которое мы сформулировали так: «Архитектура предусматривает простые и эффективные средства преобразования и миграции данных, значительно облег­чающие размещение системы Nightingale».

Магистральных рисков для Nightingale мы выделили всего три.

1. Избыточная зависимость от конкретных коробочных продуктов. В связи с этим мы сообщили о трудностях замены базы данных и исключения про­цессора правил» а также о зависимости от старой и (вероятно) более не поддерживаемой версии уровня переносимости базы данных. Данный ма­гистральный риск представляет угрозу для коммерческого фактора удоб­ства сопровождения.

2. Неполная определенность процесса восстановления после ошибок. Недоста­точный уровень осведомленности заказчика о доступных инструменталь­ных средствах. Некоторые сценарии касались обнаружения и устранения ошибок в базе данных. Несмотря на то что соответствующие процедуры были предусмотрены в архитектуре, о некоторых из них архитекторы и проектировщики задумывались впервые. Г1о словам представителей первого заказчика, процедур, направленных на исправление ошибок, у них не было (ни собственных, ни полученных от компании-разработ­чика). Этот магистральный риск ставил под сомнение реализацию ком­мерческого фактора практичности и обеспечения работы предприятия заказчика.

3. Вопросы, связанные с документацией. Документация проекта Nightingale оказалась в неудовлетворительном состоянии. К осознанию этого недостатка группа оценки пришла уже во время проводившегося перед первым этапом совещания, а сценарии, проанализированные на втором этапе, только ут­вердили нас в таком мнении. Несмотря на наличие ряда объемных и де­тальных элементов документации (построенной, в частности, средствами UML и модели Rose), ни вступительной части, ни обзора архитектуры со­ставлено не было — а ведь без этого невозможно проводить подготовку персонала, внедрять в проект новых специалистов, сопровождать систему, координировать дальнейшую разработку и тестирование. Недокументиро­ванными также оставались обширная база правил, регламентировавшая пове­дение Nightingale, а также процедура преобразования и миграции данных. В отсутствие этой документации первый заказчик, уже готовый приобре­сти систему, не смог бы справиться с ее сопровождением; таким образом, риск распространялся на один из основных коммерческих факторов разра­ботки Nightingale — обеспечение функционирования предприятия заказ­чика.

Этап 3: доработка

Осязаемым продуктом оценки по методу ЛТЛМ является сводный отчет с перечнем рискованных и нерискованиых решений, точек чувствительности и точек комп­ромиссов. Помимо этого, в него включается каталог применяемых архитектур­ных методик, дерево полезности, сценарии, сформулированные методом мозго­вого штурма, и описание анализа всех отобранных сценариев. Наконец, в сводном отчете указываются магистральные риски, которые удалось выявить участникам

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

Как и при презентации результатов, при составлении отчета мы воспользова­лись стандартным шаблоном, многие из разделов которого уже были заполнены (в частности, раздел, посвященный описанию метода АТЛМ); остальные нам лишь предстояло заполнить. Отдельные части сводного отчета — в частности, дерево полезности и результаты анализа операции 6 — мы подготовили во время пере­рыва между первым и вторым этапами. Все эти подготовительные действия при­вели к положительному результату: если раньше на подготовку сводного отчета для заказчика оценки АТАМ уходило около двух недель, то в рассматриваемом случае нам удалось составить качественный, комплексный отчет приблизительно за два дня.

11.5. Заключение

АТАМ зарекомендовал себя как надежный метод оценки программной архитек­туры. Он подразумевает формулирование (в форме сценариев) ответственными за проект и заинтересованными лицами точного перечня требований по атрибу­там качества и исследование архитектурных решений, значимых в контексте реа­лизации всех высокоприоритетных сценариев. Путем разделения такого рода ре­шений на рискованные и нерискованные оценщикам удается выявить проблемные участки рассматриваемой архитектуры.

Одного лишь знания принципов, на которых основывается метод АТАМ, не­достаточно. Важно понимать, для каких целей он не предназначен.

♦ АТАМ не предусматривает оценки требований. Другими словами, по ре­зультатам оценки, проведенной этим методом, нельзя судить о перспекти­вах реализации всех предъявленных к системе требований. Он лишь помогает понять, удастся ли при данном проектном решении реализовать основные требования.

♦ АТАМ не предоставляет возможности оценки кода. Поскольку оценка по этому методу проводится на ранних стадиях жизненного цикла, никаких допущений относительно существования кода не делается, а средств ин­спекции кода не предусматривается.

♦ АТАМ не связан с фактическим тестированием системы. Так как, опять же, оценка АТАМ проводится на раннем этапе жизненного цикла, допущения о существовании системы и средств фактического тестирования в рассмат­риваемый метод не заложены.

♦ Не являясь точным инструментом, АТАМ выделяет в рамках архитектуры потенциальные области риска. Выражаются они в виде точек чувствитель­ности и точек компромиссов. Поскольку АТАМ основывается на знаниях архитектора, некоторые риски могут так и остаться неустановленными. Те же риски, которые удается выявить, в рамках АТАМ не подлежат количе­ственной оценке. Другими словами, оценщики не делают выводов об убыт­ках, которые могут последовать по причине неустранения топ или иной точки чувствительности. Финансовые аспекты рассматриваются в главе 12 в связи с методом анализа стоимости и эффективности (cost benefit analysis method, СВАМ).

Опенок, проведенных по методу АТАМ, на нашем счету множество; нам также доводилось наблюдать за тем, как их выполняют другие специалисты, и даже проводить посвященные этому методу занятия. Практически в каждом из этих случаев мы сталкивались с одной и той же реакцией со стороны технических специалистов — они крайне удивлялись, узнав, что за относительно короткое время можно выявить немалое количество рисков. Ответственным лицам удавалось понять, почему реализации поставленных коммерческих задач препятствуют те или иные технические проблемы. Итак, АТАМ оказался весьма полезной штукой.

11.6. Дополнительная литература

В то время, когда книгу, которую вы держите в руках, готовили к печати, мы занимались выверкой начального варианта учебного курса но АТАМ. Подробно­сти этого предприятия изложены на веб-сайте анализа компромиссных архитек­турных решений на сервере Института программной инженерии — http://www.sei. cmu.edu/ata/ata-init.html. Более подробное исследование АТАМ, сопровождаемое конкретным примером оценки спутниковой системы данных NASA, приводится в работе [Clements 02а].

Довольно необычно требования по атрибутам качества и их связь с проектны­ми решениями трактуются в публикации [Chung 00]. В частности, в ней дается ссылка на издание [Boehm 76]. Описанное в нем дерево характеристик качества программных продуктов во многом схоже с деревьями полезности, применяемы­ми в рамках АТАМ.

Если вам интересны исторические предпосылки возникновения АТАМ и при этом вы не прочь ознакомиться со вторым (более простым) методом архитектур­ной оценки, прочитайте работу [Kazman 94], посвященную методу анализа про­граммной архитектуры (software architecture analysis method, SAAM).

11.7. Дискуссионные вопросы

1. Проанализируйте одну из важных программных систем вашей компании. Помогает ли изложенный в этой главе шаблон по части формулирования коммерческих факторов и обсуждения архитектуры в целом? Если нет, какой информации недостает? Попробуйте набросать дерево полезности рассмат­риваемой системы.

2. Предположим, что вы решили провести оценку архитектуры этой системы. Кого вы привлечете к участию в процессе? Какие роли должны будут ис­полнять заинтересованные лица и как эти роли среди них лучше всего распределить?

 

Глава 12

Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно­проектных решений

(в соавторстве с Джей Асунди^[5] и Марком Кляйном)

Тут миллиард, там миллиард — в конечном итоге получаются приличные деньги.

Эверетт Дирксен, сенатор США (1896-1969)

Как вы знаете на материале главы И, метод анализа компромиссных архитектур­ных решений (Architecture Tradeoff Analysis Method, АТАМ) позволяет архитек­торам программных систем оценивать технологические компромиссы, на кото­рые они идут при проектировании и сопровождении. Основным предметом анализа в рамках АТАМ является соотношение проектного решения архитектуры — су­ществующей или нереализованной — и значимых с точки зрения заинтересован­ных лиц атрибутов качества. Кроме того, исследованию подвергаются архитек­турные компромиссы — точки, в которых одно решение влияет на реализацию нескольких атрибутов качества.

При всем при этом АТАМ не учитывает одного важного обстоятельства — как правило, наиболее значительные компромиссы в сложных системах оказываются завязанными на экономические факторы. Как компании следует распределить ресурсы, чтобы максимизировать доходы и минимизировать риски? Раньше этот вопрос решался в основном исходя из стоимости конструирования системы, причем долговременные издержки, связанные с прохождением циклов сопровожде­ния и обновления, в расчет обычно не принимались. Не менее (а возможно, и бо­лее) важны выгоды, которые приносит компании то или иное архитектурное ре­шение.

Учитывая ограниченность ресурсов, применяемых при конструировании и со­провождении системы, явственно ощущается потребность в некоем рациональ­ном процессе, облегчающем процесс выбора архитектурных альтернатив на этапе первоначального проектирования и в последующие периоды обновления. Аль­тернативы эти различаются по издержкам, потреблению ресурсов и реализации характеристик (каждая из которых приносит компании те или иные выгоды); кроме того, выбор сам по себе — предприятие в некоторой степени рискованное и неясное. Для выявления всех этих аспектов необходимы экономические модели программных систем, учитывающие издержки, выгоды, риски и временные огра­ничения.

Имея в виду упростить принятие решений экономического характера, мы раз­работали метод экономического моделирования программных систем, ориенти­рованный на анализ вариантов их архитектуры. Известный под названием мето­да анализа стоимости и эффективности (Cost Benefit Analysis Method, СВАМ) и базирующийся на АТАМ, он обеспечивает моделирование затрат и выгод, свя­занных с принятием архитектурно-проектных решений, и способствует их опти­мизации. Методом СВАМ оцениваются технологические и экономические фак­торы, а также сами архитектурные решения.

12.1. Контекст принятия решений

Все программные архитекторы и ответственные лица стремятся довести до мак­симума разницу между выгодами, полученными от системы, и стоимостью реа­лизации ее проектного решения. Являясь логическим продолжением метода АТАМ, СВАМ основывается на его артефактах. Контекст СВАМ изображен на рис. 12.1.

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

Как вы помните, по результатам оценки программной системы по методу АТАМ в нашем распоряжении оказался ряд документированных артефактов.

♦ Описание коммерческих задач, определяющих успешность системы.

♦ Набор архитектурных представлений, документирующих существующую или предложенную архитектуру.

Рис. 12.1. Контекст метода анализа стоимости и эффективности (СВАМ) сценариев.

♦ Дерево полезности, выражающее декомпозицию задач, которые заинтере­сованные лица ставят перед архитектурой, — от обобщенных формулиро­вок атрибутов качества до конкретных

 

 

♦ Ряд выявленных рисков.

♦ Ряд точек чувствительности (архитектурных решений, которые оказывают влияние на отдельный показатель атрибута качества).

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

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

АТАМ обнаруживает архитектурные решения, принятые относительно рас­сматриваемой системы, и устанавливает их связь с коммерческими задачами и ко­личественной мерой реакции атрибутов качества. Принимая эти данные на воо­ружение, СВАМ помогает выявить связанные с такими решениями издержки и выгоды. Основываясь на этой информации, заинтересованные лица могут при­нять окончательные решения относительно резервирования аппаратной части, введения контрольных точек и всех прочих тактик, направленных на повышение готовности системы. Вполне возможно, что они предпочтут сконцентрировать ресурсы, которые, как известно, ограниченны, на реализацию какого-то другого атрибута качества — например, на улучшение соотношения выгод и издержек за счет повышения производительности. Из-за ограниченности бюджета разработ­ки и обновления системы каждое архитектурное решение, по большому счету, соревнуется за право па существование со всеми остальными.

Подобно финансовому консультанту, который никогда напрямую не укажет, во что вкладывать деньги, СВАМ не заменяет собой решений, принимаемых за­интересованными лицами. Он лишь помогает им установить и документировать издержки и выгоды архитектурных инвестиций, осознать неопределенность это­го «портфеля»; на этой основе заинтересованные лица могут принимать рацио­нальные решения, удовлетворяющие их потребности и сводящие к минимуму риски.

Короче говоря, метод СВАМ исходит из предположения о том, что архитек­турные стратегии (как совокупность архитектурных тактик) оказывают влияние на атрибуты качества системы, а те, в свою очередь, предоставляют заинтересо­ванным лицам некоторые выгоды. Эти выгоды мы называем полезностью (utility). Любая архитектурная стратегия отличается той или иной полезностью для заин­тересованных лиц. С другой стороны, есть издержки (стоимость) и время, кото­рые необходимо потратить на реализацию этой стратегии. Отталкиваясь от этой информации, метод СВАМ помогает заинтересованным лицам в процессе выбо­ра архитектурных стратегий, характеризующихся максимальной прибылью па инвестированный капитал (return on investment, ROI), — другими словами, наи­более выгодных с точки зрения соотношения выгод и издержек.

12.2. Основы СВАМ

Ниже мы рассмотрим, принципы, составляющие основу метода СВАМ. Их прак­тическая реализация в виде последовательности этапов описывается в разделе 12.3. Предварительно вы должны разобраться с теоретической стороной расчета коэф­фициента ROI для различных архитектурных стратегий с учетом отобранных заинтересованными лицами сценариев.

Для начала рассмотрим ряд сценариев, сформулированных в рамках АТАМ (или специально для оценки по методу СВАМ). Их следует исследовать на пред­мет различий по ценности предполагаемых реакций, а затем классифицировать полученные результаты по критерию полезности. Полезность определяется зна­чимостью каждого рассматриваемого сценария с учетом предполагаемого значения реакции. Далее рассматриваются архитектурные стратегии, приводящие к раз­личным предполагаемым реакциям. Каждая стратегия характеризуется издерж­ками и воздействием на несколько атрибутов качества. Иначе говоря, архитек­турная стратегия, которая изначально реализуется с целыо достижения желаемой реакции, попутно оказывает влияние на другие атрибуты качества. Полезность этих «побочных эффектов» необходимо учитывать при расчете общей полезно­сти стратегии — ведь именно из общей полезности, прибавленной к проектной стоимости архитектурной стратегии, складывается окончательная величина ROI.

Полезность

При расчете полезности внимание обращается на проблемы, описанные в ниже­следующих разделах.

 

Вариации сценариев

По аналогии с АТАМ, сценарии в СВАМ применяются как механизм конкретно­го выражения и представления отдельных атрибутов качества. Так же как и в АТАМ, сценарии здесь разделяются на три части: стимул (взаимодействие с си­стемой), условия (состояние системы в данный момент) и реакцию (результиру­ющий атрибут качества, поддающийся количественной оценке). Впрочем, между упомянутыми методами есть и различия. В СВАМ, к примеру, сценарии задей­ствуются целыми наборами (которые составляются путем варьирования значе­ний реакции), в то время как АТАМ имеет дело с отдельными сценариями. Отсю­да понятие кривой «реакция-полезность».

Кривые «реакция-полезность»

Каждая пара значений стимула-реакции в рамках сценария в какой-то степени полезна для заинтересованных лиц; более того, полезность возможных значений реакции можно сравнивать. К примеру, заинтересованные лица вряд ли оценят максимальную готовность в качестве реакции на отказ значительно выше, чем готовность умеренную. С другой стороны, низкая задержка, очевидно, имеет шансы на значительно более серьезную оценку по сравнению с умеренной задержкой. Любое отношение между набором величин полезности и соответствующим набо­ром величин реакции можно выразить в виде графика, называемого кривой «ре­акция-полезность». Несколько примеров таких кривых приводятся на рис. 12.2. Точки с метками о, b и с на каждой из них выражают различные величины реак­ции. Таким образом, полезность на такой кривой изображается как функция от величины реакции.

Кривая «реакция-полезность» демонстрирует изменение величин полезности в зависимости от изменения величин реакции. Как видим на рис. 12.2, полез­ность может изменяться линейно, нелинейно и ступенчато. К примеру, график (с) демонстрирует значительное повышение полезности при ограниченном измене­нии уровня реакции атрибута качества, что соответствует вышеприведенному примеру с производительностью. Пример с готовностью лучше сочетается с гра­фиком (а), где умеренное изменение уровня реакции приводит к едва заметному изменению полезности для пользователя.

Допытываться у заинтересованных лиц относительно характеристик полезно­сти долго и утомительно. По этой причине для каждого сценария мы выбрали всего по пять значений реакции атрибута качества, посчитав, что приближенных величин будет вполне достаточно. Четыре из них универсальны для любых архи­тектурных стратегий, и о них мы поговорим прямо сейчас. Заметим лишь, что пятое значение, рассматриваемое далее по тексту, зависит от конкретной архи­тектурной стратегии.

с Рис. 12.2. Несколько примеров кривых «реакция-полезность»

Для того чтобы построить кривую «реакция-полезность», в первую очередь необходимо установить уровни атрибута качества в наилучшим и в наихудшем случаях. На уровне наилучшего случая атрибута качества заинтересованные лица усматривают максимальную полезность. К примеру, реакция системы на действия пользователя, происходящая за период времени в 0,1 с, воспринимается как мгно­венная; таким образом, сокращение этого периода до 0,03 с бесполезно. Уровень наихудшего случая атрибута качества — это нижний предел, на котором система может функционировать; если он не соблюдается, в глазах заинтересованных лиц система теряет смысл. Эти уровни — наилучшего и наихудшего случая — соответствуют значениям полезности 100 и 0 соответственно.

 

Далее, для каждого сценария необходимо определить текущий (current) и же­лаемый (desired) уровни полезности. Значения полезности (находящиеся между 0 и 100) текущего и желаемого уровней определяются по показаниям заинтересо­ванных лиц, причем значения наилучшего и наихудшего случаев используются как опорные точки (предположим, что в данный момент полезность считается 50-процентной, а желаемый уровень полезности атрибута качества находится на отметке 90 % максимально возможной полезности; соответственно, текущий уро­вень полезности приравнивается к 50, а желаемый — к 90). Таким способом кри­вые составляются для любых сценариев.

Расстановка приоритетов среди сценариев

Различные сценарии, сформулированные в рамках данной системы, имеют для заинтересованных лиц разную важность и, соответственно, характеризуются разной полезностью* Относительная значимость каждого сценария выражается через его вес (weight), назначаемый по результатам двухэтапной процедуры голо­сования. На первом этапе заинтересованные лица путем подачи голосов упорядо­чивают сценарии. Исходят они при этом из «предполагаемого» значения реак­ции. После этого заинтересованные лица присваивают наиболее приоритетному сценарию вес 1, а всем остальным, в зависимости от их относительной значимо­сти» дробные значения.

Если в какой-то момент в будущем появится потребность во введении новых сценариев, им также нужно будет присвоить значение веса. Совещательным пу­тем заинтересованные лица приводят значения веса в согласие со своими пред­ставлениями.

Архитектурные стратегии

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