Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Глава 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, и, отталкиваясь от него, значения веса устанавливаются для всех остальных сценариев. Именно эти значения впослед­ствии задействуются при вычислении общей выгоды стратегии. Помимо прочего, на рассматриваемом этапе составляется список атрибутов качества, которые за­интересованные лица считают значимыми.

 

Рис. 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 заключается в том, чтобы представить эти данные в форме более высокого уров-

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

За один день 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 Тбайт)

Таблица 12.2. Задачи по реакции для уточненных сценариев

Сценарий   Задачи по реакции  
  Наихудший Текущий Желаемый Наилучший
  случай уровень уровень случай
Зависание 10% Зависание 5% Зависание 1% Зависание 0%
Потери > 5% Потери < 1% Потери 0% Потери 0%
Отказы 10% Отказы 5% Отказы 1% Отказы 0%
Зависание 10% Зависание 5% Зависание 1% Зависание 0%
Потери 10% Потери < 1% Потери 0% Потери 0%
Помощь требуется Помощь требуется Помощь требуется Помощь требуется
  в 50% случаев в 25% случаев в 0% случаев в 0% случаев
Получение Получение Получение Получение
  информации информации информации информации
  в 10% случаев в 50% случаев в 100% случаев в 100% случаев
Ограничения Ограничения Ограничения Ограничения
  в 50 %случаев в 30% случаев в 0% случаев в 0% случаев
1 оповещение 1 оповещение 1 оповещение 1 оповещение
  на 1 гранулу на 1 гранулу на 100 гранул на 1000 гранул
Задача решается Задача решается Задача решается Задача решается
  менее чем в 60% случаев в 80% случаев более чем
  в 50% случаев     в 90% случаев

 

 

Этап 3: расстановка сценариев согласно приоритетам

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

Таблица 12.3. Уточненные сценарии и количество поданных за них голосов
Сце­ нарий Голоса Наихудший случай Задачи по реакции Текущий Желаемый уровень уровень Наилучший случай
Зависание 10% Зависание 5% Зависание 1% Зависание 0%
Потери > 5% Потери < 1% Потери 0% Потери 0%
Отказы 10% Отказы 5% Отказы 1% Отказы 0%
Зависание 10% Зависание 5% Зависание 1% Зависание 0%
Потери 10% Потери < 1% Потери 0% Потери 0%
Помощь требуется Помощь требуется Помощь требуется Помощь требуется
    в 50% случаев в 25% случаев в 0% случаев в 0% случаев
Получение Получение Получение Получение
    информации информации информации информации
    в 10% случаев в 50% случаев в 100% случаев в 100% случаев
Ограничения Ограничения Ограничения Ограничения
    в 50% случаев в 30% случаев в 0% случаев в 0% случаев
1 оповещение 1 оповещение 1 оповещение 1 оповещение
    на 1 гранулу на 1 гранулу на 100 гранул на 1000 гранул
Задача решается Задача решается Задача решается Задача решается
    менее чем в 60% случаев в 80% случаев более чем
    в 50% случаев     в 90% случаев
             

 

Этап 4: установление полезности

Полезность каждого сценария на этом этапе, опять же, определялась заинтересова- ными лицами согласованно. Нулевая сумма баллов полезности должна была обозначать отсутствие таковой; сумма балов, равная 100, напротив, указыва­ла на максимально возможную полезность. Результаты обсуждения представ­лены в табл. 12.4.

 

Таблица 12.4. Голоса, поданные за сценарии, и суммы полученных ими баллов
Сценарий Голоса Наихудший случай Задачи по реакции Текущий Желаемый уровень уровень Наилучший случай

 

Этап 5: разработка для сценариев архитектурных стратегий и установление их желаемых уровней реакции атрибута качества

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

Набор архитектурных стратегий, а также определения сценариев, с которыми они связаны, представлены в табл. 12.5. Для каждой пары «архитектурная стра­тегия/сценарий» показаны ожидаемые уровни реакции относительно конкретно­го сценария (для сравнения также приводятся текущие уровни реакции).

Таблица 12.5. Архитектурные стратегии и сценарии, с которыми они связаны
Стра­ тегия Имя Описание Связан­ные сце­нарии Текущий уровень реакции Ожидаемый уровень реакции
Персистент­ Сохранение заказа Отказы 5% Отказы 2%
  ность заказов происходит сразу после его      
  при подаче поступления в систему      
      Потери < 1 % Потери 0%
      Помощь Помощь
        требуется требуется
        в 25% случаев в 0% случаев
Разбиение Операторам разрешается Ограничения Ограничения
  заказов разделять крупные заказы   в 30% случаев в 15% случаев
    на несколько мелких      
Группировка Ряд мелких заказов 1 оповещение 1 оповещение
  заказов объединяется в один   на 1 гранулу на 100 гранул
    крупный      

 

Стра­ Имя Описание Связан­ Текущий Ожидаемый
тегия     ные сце­нарии уровень реакции уровень реакции
      Задача решается в 60% случаев Задача решается в 55%случаев
Сегментация заказов Оператору разрешается пропускать элементы, извлечение которых из-за низкого качества данных или проблем с готовностью невозможно Зависание 5% Зависание 2%
Переназна­чение в заказах Оператору разрешается переназначать для элементов заказа типы носителей Зависание 5% Зависание 2%
Повторное выполнение заказов Заказы, выполнить которые с первого раза из-за временных сбоев в системе или проблем с данными не удалось, оператор может пытаться выполнить повторно Зависание 5% Зависание 3%
Силовое завершение заказов Оператору разрешается подменять неготовность элемента, обусловленную ограничениями на качество данных Зависание 5% ► Зависание 3%
Оповещение Пользователи должны Помощь Помощь
  о неудавшихся получать оповещения лишь   требуется требуется
  заказах о (частично) неудавшихся   в 25% случаев в 20% случаев
    заказах, а сопровождаться      
    они должны подробной Получение Получение
    информацией о состоянии   информации информации
    каждого элемента; отправку в 50% случаев в 90% случаев
    пользователям оповещений      
    должен утверждать      
    оператор; он же может их      
    редактировать      
Отслежива­ Оператор и пользователи Помощь Помощь
  ние гранул могут в порядке   требуется требуется
  согласно очередности определять   в 25% случаев в 10% случаев
  уровню состояние элементов заказа    
      Получение информации Получение информации
        в 50% случаев в 95% случаев
Ссылки на Оператор может быстро Получение Получение
  информацию находить контактную   информации информации
  о пользова­ информацию пользователя. в 50% случаев в 60% случаев
  теле Путем обращения сервера к информации SDSRV определяются возможные ограничения на данные.      

Стра- Имя Описание Связан- Текущий Ожидаемый
тегия   ные сце- уровень уровень
    нарии реакции реакции
  Кроме того, сервер    
  осуществляет маршрутиза­    
  цию заказов/сегментов    
  заказов соответствующим    
  средствам распределения:    
  DDIST, PDS, внешним меха­    
  низмам подключения,    
  инструментам обработки    
  данных и т. д.    

 







Дата добавления: 2015-04-16; просмотров: 266. Нарушение авторских прав


Рекомендуемые страницы:


Studopedia.info - Студопедия - 2014-2019 год . (0.008 сек.) русская версия | украинская версия