Глава 11 5 страница
♦ ожидаемое значение реакции в каждом сценарии (полезность ожидаемого значения определяется путем интерполяции четырех значений, установленных при участии заинтересованных лиц); ♦ воздействие архитектурной стратегии на другие значимые атрибуты; ♦ стоимость реализации архитектурной стратегии. Побочные эффекты Как правило, архитектурные стратегии влияют на разные атрибуты качества — как относящиеся, так и не относящиеся к текущему сценарию (именно по этой причине существуют архитектурные компромиссы!). Определить полезность побочных реакций атрибута, появляющихся в результате применения данной архитектурной стратегии, совершенно необходимо. В крайнем случае следует создать новую версию сценария для побочного атрибута и построить кривую «реакция- полезность». На практике все значимые для заинтересованных лиц атрибуты качества обычно фигурируют сразу в нескольких сценариях, а значит, лишний раз строить кривые «реакция-полезность» не приходится. Единственное, что в таком случае нужно установить, — это ожидаемая полезность, связанная с данным атрибутом качества для данной архитектурной стратегии. Обратите внимание — если архитектурная стратегия задумана для того, чтобы подчеркнуть конфликт одного атрибута с другим — тем, над подсчетом полезности которого в данный момент идет работа, — то ожидаемая полезность может быть отрицательной. При наличии вышерассмотренной дополнительной информации можно сложить выгоды от применения данной архитектурной стратегии для отдельных значимых атрибутов качества и тем самым установить общие выгоды. Определение выгод и нормализация Для того чтобы на основе кривых «реакция-полезность» вычислить общую полезность применения архитектурной стратегии дли нескольких сценариев, достаточно сложить полезность для каждого из них в отдельности (пес сценариев при этом определяется его значимостью). Так, для любой архитектурной стратегии i выгода Bi вычисляется по формуле:
где bij — это выгода, извлеченная из стратегии i в силу ее воздействия на сценарий/, a Wj — вес сценария j. Каждое значение bt 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, и, отталкиваясь от него, значения веса устанавливаются для всех остальных сценариев. Именно эти значения впоследствии задействуются при вычислении общей выгоды стратегии. Помимо прочего, на рассматриваемом этапе составляется список атрибутов качества, которые заинтересованные лица считают значимыми.
Этап 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 заключается в том, чтобы представить эти данные в форме более высокого уров- ня, допускающий анализ и поиск. Необходимо одновременно предусмотреть универсальный способ хранения (и, следовательно, обработки) данных и общедоступный механизм введения новых форматов данных и алгоритмов обработки; в конечном итоге, информация должна стать доступной для всех желающих. За один день ECS обрабатывает сотни гигабайт сырых данных об окружающей среде — все они поступают в систему в виде входного потока. По результатам вычисления 250 стандартных «продуктов» генерируется несколько тысяч гигабайт информации, архивируемой в восьми информационных центрах, расположенных на территории Соединенных Штатов. Важнейшие требования в системе относятся к производительности и готовности. Кроме того, долговременный характер подразумевает внимание к модифицируемости. Руководитель проекта ECS, имея в своем распоряжении ограниченный годовой бюджет, должен был распределить его па нужды сопровождения текущей системы и ее модернизации. В ходе проведенных ранее аналитических действий (по методу АТАМ) со слов заинтересованных лиц удалось зафиксировать множество желательных изменений и соответствующих им архитектурных стратегий. Поскольку из всего предложенного бюджета хватало лишь на 10-20 %, задача заключалась в том, чтобы выбрать для реализации относительно небольшой набор изменений. С помощью СВАМ руководитель проекта установил коэффициенты прибыли на инвестированный капитал, и исходя из этого экономического критерия ему удалось принять рациональное решение. Потенциал метода СВАМ в описываемом случае мы направили на анализ одного из элементов ECS — рабочей группы по доступу к данным (Data Access Working Group, DAWG). Этап 1: критический анализ сценариев Для сверки сценариев, зафиксированных во время анализа по методу АТАМ, мы еще раз собрали заинтересованных в системе ECS лиц и установили ряд новых сценариев. Поскольку у всех участников этой процедуры уже был опыт работы с АТАМ, никаких сложностей у нас не возникло. Сценарии, выбранные группой DAWG, перечислены в табл. 12.1. Имейте в виду, что они не слишком удачно сформулированы, а для некоторых даже не определены реакции. Вопросы эти решаются на этапе 2, когда количество сценариев существенно уменьшается[6]. Этап 2: уточнение сценариев При уточнении сценариев мы уделили особое внимание точному определению количественных показателей стимула-реакции. Как показано в табл. 12.2, для каждого сценария мы установили и зафиксировали наихудший, текущий, желаемый и наилучший случаи:
Таблица 12.2. Задачи по реакции для уточненных сценариев
1. Сокращение отказов при распределении данных, приводящих к зависанию запросов на распределение и требующих ручного вмешательства 2. Сокращение отказов при распределении, приводящих к потере запросов на распределение 3. Сокращение количества заказов, отказавших в процессе подачи 4. Сокращение отказов при заказах, приводящих к зависанию и требующих ручного вмешательства 5. Сокращение отказов при заказах, приводящих к их потере 6. Отсутствие приемлемого метода отслеживания неудавшихся/отмененных заказов, поданных от имени ECSGuest, который предусматривал бы минимизацию ручного вмешательства (например, электронные таблицы) 7. Пользователю требуется дополнительная информация о причинах отказа при подаче заказа или получении данных 8. Из-за определенных ограничений приходится устанавливать искусственные пределы размера и количества заказов 9. В результате заказов малого объема пользователи получают слишком много оповещений 10 Система должна обеспечивать обработку пользовательских заказов за один день (если их объем не превышает 50 Гбайт) или за одну неделю (если их объем достигает 1 Тбайт)
Этап 3: расстановка сценариев согласно приоритетам В том, что касается голосования по вопросу об уточнении сценариев, группа специалистов по оценке сделала небольшое отступление от традиционной схемы метода. Вместо того чтобы организовать поименное голосование, они приняли решение обсудить каждый сценарий но отдельности и определиться с весом общими усилиями. На весь набор сценариев выделили 100 голосов (табл. 12.3). Изначально от заинтересованных лиц не требовалось подачи голосов, кратных пяти, однако они пришли к мнению, что более серьезная точность, во-первых, не нужна, а во-вторых, ничем не оправдана.
Этап 4: установление полезности Полезность каждого сценария на этом этапе, опять же, определялась заинтересова- ными лицами согласованно. Нулевая сумма баллов полезности должна была обозначать отсутствие таковой; сумма балов, равная 100, напротив, указывала на максимально возможную полезность. Результаты обсуждения представлены в табл. 12.4.
Этап 5: разработка для сценариев архитектурных стратегий и установление их желаемых уровней реакции атрибута качества Исходя из требований, подразумеваемых вышеперечисленными сценариями, архитекторы ECS разработали 10 архитектурных стратегий. Как вы помните, любая отдельно взятая архитектурная стратегия может оказывать воздействие сразу на несколько сценариев. Учитывая такую сложность отношений, ожидаемый уровень реакции атрибута качества для каждой из стратегий пришлось устанавливать относительно всех значимых сценариев. Набор архитектурных стратегий, а также определения сценариев, с которыми они связаны, представлены в табл. 12.5. Для каждой пары «архитектурная стратегия/сценарий» показаны ожидаемые уровни реакции относительно конкретного сценария (для сравнения также приводятся текущие уровни реакции).
|
Рис. 12.3. Диаграмма процессов СВАМ
