Затраты 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, а всем остальным, в зависимости от их относительной значимо­сти» дробные значения.

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

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

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

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

♦ воздействие архитектурной стратегии на другие значимые атрибуты;

♦ стоимость реализации архитектурной стратегии.

Побочные эффекты

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

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

Определение выгод и нормализация

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

где bij — это выгода, извлеченная из стратегии i в силу ее воздействия на сцена­рий/, a Wj — вес сценария j. Каждое значение b_{t J} на рис. 12.2 выражает изменение полезности сценария, вызванное применением данной архитектурной стратегии: Kj ^в ^ожидаемая “ ^куша^ иначе говоря, оно равняется полезности ожидаемого зна­чения архитектурно!! стратегии в отношении данного сценария за вычетом теку­щей полезности системы. Как мы уже говорили, за счет умножения на вес (Wj) полученное значение полезности нормализуется относительной значимостью того или иного сценария.

Вычисление коэффициента ROI

Коэффициент ROI для любой архитектурной стратегии равняется частному от деления общей выгоды (5,) на издержки (С,) реализации. Издержки рассчитыва­ются по модели, наиболее подходящей для разрабатываемой системы и ее окру­жения:

Исходя из полученного значения архитектурные стратегии подвергаются ран­жированию; впоследствии ранги помогают определить оптимальный порядок реализации различных стратегий.

Рассмотрим изображенные на рис. 12.2 кривые (а) и (/;). По мере возрастания реакции атрибута качества кривая (а) «расплющивается». В данном случае точ­ка, после которой ROI начинает снижаться, несмотря на повышение реакции атрибута качества, скорее всего, уже достигнута. Другими словами, вкладывать более серьезные средства не имеет смысла, так как они не приведут к значитель­ному повышению полезности. Теперь взглянем на кривую (6), на которой едва заметное повышение реакции атрибута качества приводит к «взлету» полезно­сти. Таким образом, для того чтобы серьезно повысить ROI данной архитектур­ной стратегии, достаточно немного увеличить реакцию атрибута качества.

О ВАЖНОСТИ МОДЕЛИРОВАНИЯ ЗАТРАТ------------------------- —

Случайный посетитель: Мне говорили, вы разбираетесь в вопросах готовности...

Лен Басс: Да, я кое-что знаю, но, вообще-то, я не эксперт.

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

ЛБ: Ну, у них, наверное, миллионы клиентов, и поэтому требования по готовности, скорее всего, очень жесткие.

СП: В том-то все и дело. У системы, которую я разрабатываю, будет всего несколько со­тен пользователей, которым вполне достаточно готовности по пять 10-часовых дней в неде­лю. Так вот, как мне убедить начальника в том, что он слишком много хочет?

Изложив множество методов реализации различных атрибутов качества, мы до сих пор не говорили о том, как держать в узде ожидания ответственных лиц. Мы все время предполага­ли, что разработкой системы движут некие коммерческие факторы. Эти факторы порождают определенные требования, и задача архитектора состоит в том, чтобы обеспечить их макси­мальное удовлетворение. Но что делать, если наше допущение оказывается несостоятель­ным и в сеете коммерческих задач системы требования оказываются избыточными?

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

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

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

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

-UB

12.3. Реализация СВАМ

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

Этапы

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

Этап 1: критический анализ сценариев. Критический анализ сценариев прово­дится в рамках АТАМ; на этом же этапе заинтересованные лица могут формулиро­вать новые сценарии. Приоритеты расставляются в соответствии с потенциалом сценариев в контексте выполнения коммерческих задач системы; по результатам этапа для дальнейшего рассмотрения отбирается треть от общего первоначально­го числа сценариев.

Этап 2: уточнение сценариев. Уточнению подвергаются сценарии, отобран­ные по результатам первого этапа; основное внимание при этом уделяется их значениям стимула-реакции. Для каждого сценария устанавливаются наихуд­ший, текущий, желаемый и наилучший уровни реакции атрибута качества.

Этап 3: расстановка сценариев согласно приоритетам. Каждому заинте­ресованному лицу выделяется 100 голосов, которые он берется распределить между сценариями, исходя из их желаемых значений реакции. После подсчета голосов для дальнейшего анализа остается только половина сценариев. Сценарию с наи­высшим рангом присваивается вес 1.0, и, отталкиваясь от него, значения веса устанавливаются для всех остальных сценариев. Именно эти значения впослед­ствии задействуются при вычислении общей выгоды стратегии. Помимо прочего, на рассматриваемом этапе составляется список атрибутов качества, которые за­интересованные лица считают значимыми.

Рис. 12.3. Диаграмма процессов СВАМ

Этап 4: установление полезности. Для сценариев, оставшихся после прове­дения этапа 3, определяются значения полезности всех уровней реакции (наи­худшего, текущего, желаемого, наилучшего) атрибута качества.

Этап 5:разработка для сценариев архитектурных стратегий и установ­ление их желаемых уровней реакции атрибута качества. Разработка (или фиксация разработанных) архитектурных стратегии, ориентированных на реали­зацию выбранных сценариев, и определение «ожидаемых» уровней реакции ат­рибута качества. Учитывая то обстоятельство, что одна архитектурная стратегия иногда оказывает воздействие на несколько сценариев, расчеты необходимо про­вести для каждого из затронутых сценариев.

Этап 6: определение полезности «ожидаемых» реактивных уровней ат­рибута качества путем интерполяции. Исходя из установленных значений полезности (отраженных на кривой полезности) для рассматриваемой архитек­турной стратегии определяется полезность желаемого уровня реакции атрибута качества. Эта операция проводится для каждого из перечисленных на этапе 3 значимых атрибутов качества.

Этап 7: расчет общей выгоды, полученной от архитектурной стратегии. Значение полезности «текущего» уровня вычитается из желаемого уровня и нор­мализуется исходя из поданных на третьем этапе голосов. Суммируются выгоды, полученные от конкретной архитектурной стратегии, по всем сценариям и для всех значимых атрибутов качества.

Этап 8: отбор архитектурных стратегий с учетом ROI, а также огра­ничений по стоимости и времени. Для каждой архитектурной с тратегии определя­ются стоимостные и временные факторы. Значение ROI для стратегий определяет­ся как отношение выгоды к издержкам. Архитектурные стратегии упорядочиваются по рангу согласно значениям ROI; впоследствии бюджет в первую очередь расхо­дуется на высшие по рангу стратегии.

Этап 9: интуитивное подтверждение результатов. Проверяется соответствие выбранных архитектурных стратегий коммерческим задачам компании. Если на­блюдаются противоречия, ищем недосмотры во время проведения анализа. В слу­чае, если противоречия значительны, перечисленные этапы проводятся повторно.

12.4. Конкретный пример: проект ESC агентства NASA

Рассмотрим случай практического применения метода СВАМ к реальной си­стеме.

Система наблюдения за поверхностью Земли (Earth Observing System, EOS) — это группа спутников NASA, осуществляющих сбор информации для американ­ской исследовательской программы глобальных изменений (US Global Change Research Program), а также ряда других научно-исследовательских организаций, базирующихся в различных странах мира. Центральная информационная систе­ма наблюдения за поверхностью Земли (Earth Observing System Data Information System Core System, ECS) собирает с ряда искусственных спутников с нисходя­щей связью данные, которые впоследствии подвергаются обработке. Задача ECS заключается в том, чтобы представить эти данные в форме более высокого уров-

Дата добавления: 2015-04-25