Затраты 6 страница

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

За один день ECS обрабатывает сотни гигабайт сырых данных об окружающей среде — все они поступают в систему в виде входного потока. По результатам вычисления 250 стандартных «продуктов» генерируется несколько тысяч гигабайт информации, архивируемой в восьми информационных центрах, расположенных на территории Соединенных Штатов. Важнейшие требования в системе относятся к производительности и готовности. Кроме того, долговременный характер подразумевает внимание к модифицируемости.

Руководитель проекта ECS, имея в своем распоряжении ограниченный годовой бюджет, должен был распределить его па нужды сопровождения текущей системы и ее модернизации. В ходе проведенных ранее аналитических действий (по методу АТАМ) со слов заинтересованных лиц удалось зафиксировать множество желательных изменений и соответствующих им архитектурных стратегий. Поскольку из всего предложенного бюджета хватало лишь на 10-20 %, задача заключалась в том, чтобы выбрать для реализации относительно небольшой набор изменений. С помощью СВАМ руководитель проекта установил коэффициенты прибыли на инвестированный капитал, и исходя из этого экономического критерия ему удалось принять рациональное решение.

Потенциал метода СВАМ в описываемом случае мы направили на анализ одного из элементов ECS — рабочей группы по доступу к данным (Data Access Working Group, DAWG).

Для сверки сценариев, зафиксированных во время анализа по методу АТАМ, мы еще раз собрали заинтересованных в системе ECS лиц и установили ряд новых сценариев. Поскольку у всех участников этой процедуры уже был опыт работы с АТАМ, никаких сложностей у нас не возникло.

Сценарии, выбранные группой DAWG, перечислены в табл. 12.1. Имейте в виду, что они не слишком удачно сформулированы, а для некоторых даже не определены реакции. Вопросы эти решаются на этапе 2, когда количество сценариев существенно уменьшается^{^[6]}.

При уточнении сценариев мы уделили особое внимание точному определению количественных показателей стимула-реакции. Как показано в табл. 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% случаев

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

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

За определением относительного набора сценариев ожидаемого уровня реакции каждой архитектурной стратегии следует расчет их полезности. Для этого следует обратиться к суммам баллов полезности текущей и желаемой реакции для всех задействованных атрибутов. Исходя из этих значений путем интерполяции можно вычислить полезность ожидаемых уровней реакции атрибута качества для пар «архитектурная стратегия/сценарий», реализуемых с подсистемой DAWG системы ECS.

Таблица 12.6. Архитектурные стратегии и их ожидаемая полезность

Стратегия	Имя	Связанные	Текущая	Ожидаемая
		сценарии	полезность	полезность
	Персистентность заказов
	при подаче

	Разбиение заказов
	Г руппировка заказов

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

Результаты расчета для пар «архитектурная стратегия/сценарий»» представленных в табл. 12.5, приведены в табл. 12.6.

Этап 7: расчет общей выгоды, полученной от архитектурной стратегии

Таблица 12.7. Общая выгода, полученная от архитектурных стратегий

Страте гия	Связанный сценарий	Вес сценария	Ненормализованная выгода от архитектурной стратегии	Нормализованная выгода от архитектурной стратегии	Общая выгода от архитектурной стратегии





			-5	-25

На основе представленной в табл. 12.6 информации можно рассчитать общую выгоду, полученную от применения каждой архитектурной стратегии; этой цели служит уравнение, которое мы привели в подразделе «Определение выгод и нормализация». В нем общая выгода рассчитывается как сумма значений выгоды от каждого сценария, а затем нормализуется относительным весом данного сценария. Баллы общей выгоды для каждой из рассмотренных архитектурных стратегий приводятся в табл. 12.7.

Этап 8: отбор архитектурных стратегий с учетом ROI, а также ограничений по стоимости и времени

На завершающей стадии анализа участники группы оценки определили стоимость реализации всех архитектурных стратегий. Расчеты проводились исходя из опыта работы с системой, и в конечном итоге для каждой архитектурной стратегии удалось установить коэффициент прибыли на инвестированный капитал (ROI). Соответственно, у нас появилась возможность ранжировать стратегии (табл. 12.8). Неудивительно, что ранги примерно соответствуют порядку предложения стратегий: у первой стратегии высший ранг, а у третьей — второй после нысшего. Нижайший ранг у десятой стратегии, а второй с конца — у восьмой. Таким образом, проведенные расчеты подтверждают интуитивное понимание заинтересованными лицами выгод от различных архитектурных стратегий. И действительно, в случае с ECS наибольшие выгоды обещают принести первые две предложенные стратегии.

Таблица 12.8. Коэффициенты ROI различных архитектурных стратегий

Страте гия	Издержки	Общая выгода от применения стратегии	Коэффициент ROI стратегии	Ранг стратегии
			0,79
			0,5
			0,69
			0,5
			0,3
			0,25
			0,35
			0,5
			0,22
			0,25

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

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

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

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

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

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