Метод упрощенного анализа архитектурных альтернатив - История изменений

Admin: /* Этапы */

2022-05-21T23:45:39Z

‎Этапы

Admin в 14:10, 18 августа 2019

2019-08-18T14:10:15Z

Admin: /* Этапы */

2017-12-20T11:06:56Z

‎Этапы

Admin: Новая страница: «'''Метод упрощенного Анализ компромиссов#Анализ архитектуры ПО|анализа архитектурных а…»

2016-11-23T14:43:44Z

Новая страница: «'''Метод упрощенного Анализ компромиссов#Анализ архитектуры ПО|анализа архитектурных а…»

Новая страница

'''Метод упрощенного [[Анализ компромиссов#Анализ архитектуры ПО|анализа архитектурных альтернатив]]''' (Lightweight Architectural Alternative Assessment Method - LAAAM) используется для выбора [[Архитектура|архитектурной]] стратегии построения [[Программная система|приложения]]. На реализацию метода LAAAM, как правило, уходит один день.

== Этапы ==
# Построение [[дерево полезности|дерева полезности]], описывающего основные качественные и функциональные параметры приложения с учетом представленных [[Требования|требований]]. Каждый параметр записывается в виде сценария, принимающего форму оператора, включающего контекст, стимул и ответ.
#: Ключевые качественные и функциональные параметры приложения определяются в соответствии с требованиями к качеству обслуживания и требованиями к продукту. Дерево полезности представляет собой совокупность качественных параметров приложения. Корневой узел дерева помечен как "Полезность". Как правило, другие узлы характеризуются в стандартных терминах качества (возможность внесения изменений, доступность и безопасность). Дерево должно отражать иерархический характер качественных характеристик и служить основой для определения приоритетов. На каждом последующем уровне дерева качества уточняются. В конечном счете эти качества представляются в виде сценариев.
# Чтобы определить степень соответствия стратегии сценарию используется оценочная матрица.
#: Для каждого листа дерева полезности необходимо создать сценарий. Сценарий существует в форме контекста, стимула и ответа (например, "При нормальной работе транзакция базы данных должна занимать менее 100 миллисекунд"). Создается электронная или обычная таблица и вводится каждый сценарий в виде строки в получившуюся оценочную матрицу. Каждая архитектурная стратегия должна быть представлена в виде столбца. На пересечении стратегий и сценариев необходимо проставить рейтинговые баллы от 1 до 4. При этом необходимо учитывать следующие факторы:
#:* '''Затраты на разработку'''. Решение реализуется легко или сложно? Каково его влияние на другие области?
#:* '''Эксплуатационные затраты'''. Во время выполнения это решение работает без проблем или отрицательно сказывается на удобстве работы, производительности системы и т. д.?
#:* '''Риск'''. Это решение хорошо подходит для данного сценария или вероятны непредвиденные затраты? Это решение может негативно сказаться на возможностях команды реализовывать дополнительные требования в будущем?
#: Если для стратегии был создан прототип, можно использовать его данные для определения значений.
#: Внизу таблицы суммируются значения сценариев. Эти показатели используются при обсуждении альтернативных архитектур.

[[Категория:Методы]]

← Предыдущая		Версия 14:10, 18 августа 2019
Строка 12:		Строка 12:
	#: Внизу таблицы суммируются значения сценариев. Эти показатели используются при обсуждении альтернативных архитектур.		#: Внизу таблицы суммируются значения сценариев. Эти показатели используются при обсуждении альтернативных архитектур.

−	[[Категория:Методы]]	+	[[Категория:Методы оценивания]]

@@ Строка 9: / Строка 9: @@
 #:* '''Эксплуатационные затраты'''. Во время выполнения это решение работает без проблем или отрицательно сказывается на удобстве работы, производительности системы и т. д.?
 #:* '''Риск'''. Это решение хорошо подходит для данного сценария или вероятны непредвиденные затраты? Это решение может негативно сказаться на возможностях команды реализовывать дополнительные требования в будущем?
-#: Если для стратегии был создан прототип, можно использовать его данные для определения значений.
+#: Если для стратегии был создан [[прототипы|прототип]], можно использовать его данные для определения значений.
 #: Внизу таблицы суммируются значения сценариев. Эти показатели используются при обсуждении альтернативных архитектур.
 [[Категория:Методы оценивания]]

@@ Строка 3: / Строка 3: @@
 == Этапы ==
 # Построение [[дерево полезности|дерева полезности]], описывающего основные качественные и функциональные параметры приложения с учетом представленных [[Требования|требований]]. Каждый параметр записывается в виде сценария, принимающего форму оператора, включающего контекст, стимул и ответ.
-#: Ключевые качественные и функциональные параметры приложения определяются в соответствии с требованиями к качеству обслуживания и требованиями к продукту. Дерево полезности представляет собой совокупность качественных параметров приложения. Корневой узел дерева помечен как "Полезность". Как правило, другие узлы характеризуются в стандартных терминах качества (возможность внесения изменений, доступность и безопасность). Дерево должно отражать иерархический характер качественных характеристик и служить основой для определения приоритетов. На каждом последующем уровне дерева качества уточняются. В конечном счете эти качества представляются в виде сценариев.
+#: Ключевые качественные и функциональные параметры приложения определяются в соответствии с требованиями к качеству обслуживания и требованиями к продукту. Дерево полезности представляет собой совокупность качественных параметров приложения. Корневой узел дерева помечен как "Полезность". Как правило, другие узлы характеризуются в стандартных терминах качества (возможность внесения изменений, доступность и [[безопасность]]). Дерево должно отражать иерархический характер качественных характеристик и служить основой для определения приоритетов. На каждом последующем уровне дерева качества уточняются. В конечном счете эти качества представляются в виде сценариев.
 # Чтобы определить степень соответствия стратегии сценарию используется оценочная матрица.
 #: Для каждого листа дерева полезности необходимо создать сценарий. Сценарий существует в форме контекста, стимула и ответа (например, "При нормальной работе транзакция базы данных должна занимать менее 100 миллисекунд"). Создается электронная или обычная таблица и вводится каждый сценарий в виде строки в получившуюся оценочную матрицу. Каждая архитектурная стратегия должна быть представлена в виде столбца. На пересечении стратегий и сценариев необходимо проставить рейтинговые баллы от 1 до 4. При этом необходимо учитывать следующие факторы: