Глава 11 4 страница
После того как мы провели слияние нескольких почти идентичных сценариев, заинтересованные лица проголосовали. Каждому из них мы выделили по 22 голоса (30 % от 72 сценариев плюс округление до ближайшего целого числа), которые следовало подавать в два захода. Подсчитав голоса, мы вместе с участниками группы оценки на протяжении получаса дополняли составленное во время операции 5 дерево полезности новыми высокоприоритетными сценариями, которых набралось всего около десятка. Все сценарии с высоким приоритетом, выявленные в ходе операции 7, мы без лишних раздумий поместили на дерево полезности в виде новых листьев существующих ветвей. Этим мы хотели показать, что представления архитектора и заинтересованных лиц о важнейших атрибутах качества оказались сходными. Разобравшись с согласованием отдельных сценариев па дереве полезности, мы приступили к анализу тех из них, которые получили наибольшее число голосов.
Операция 8: анализ архитектурных методик В ходе операции 8 мы дополнительно провели анализ семи сценариев; следует заметить, что по меркам АТАМ это довольно много. Учитывая ограниченность объема книги, мы рассмотрим результаты одного-елинственного, 15-го сценария (см. соответствующую врезку).
Операция 9: презентация результатов Девятая операция предполагает проведение одно- или двухчасовой презентации с изложением всех достигнутых результатов и полученных выводов. В начале презентации необходимо показать слушателям набор стандартных слайдов с основными тезисами метода; кроме того, следует подготовить несколько чистых слайдов-шаблонов, на которые впоследствии нужно будет нанести сводные данные по коммерческим факторам и архитектуре, перечень методик, дерево полезности, сведения об анализе сценариев и список результатов его проведения. На втором этапе участники группы оценки должны по вечерам составлять сводки достигнутых за день результатов. Кроме того, при составлении графика второго этапа перед операцией 9 следует выделить дополнительное время, для того чтобы участники смогли встретиться и завершить работу над пакетом результатов. Помимо рискованных и нерискованных решений, точек чувствительности и компромиссов, участники группы должны выявить магистральные риски — факторы, систематически оказывающие на архитектуру негативное воздействие. Это единственный вид результатов, с которыми участники еще не имели дела (и, соответственно, не помогали их устанавливать). Значение каждого из них мы стараемся излагать так, чтобы его понял заказчик, — в частности, мы указываем на те коммерческие факторы, реализацию которых те или иные магистральные риски ставят под сомнение. СЦЕНАРИЙ 15: ПРИ УСТАНОВКЕ СИСТЕМЫ NIGHTINGALE В БОЛЬНИЦЕ НЕОБХОДИМО ПРЕОБРАЗОВАТЬ ЕЕ СУЩЕСТВУЮЩУЮ БАЗУ ДАННЫХ Нет ничего удивительного в том, что проработке этого сценария архитектор уделил особое внимание — ведь от его реализации зависел успех системы в целом. Процедуру, ранее документированную, он изобразил для нас на белой доске. Как часто бывает, анализ этого сценария помог нам лучше разобраться в архитектуре. По понятным причинам архитектор не стал останавливаться на проблеме преобразования базы данных во время презентации (операция 3), посчитав эту информацию служебной. Результаты анализа процесса миграции убедили участников группы оценки в том, что процедура тщательно продумана, ее преимущества известны, а ограничения обоснованны. Тому, что архитектор не упомянул об этом процессе во время презентации (операция 3), мы нисколько не удивились. Неожиданность заключалась в другом: в пакете документации, который мы получили и изучили еще до начала первого этапа, о нем также ничего не было сказано. В ответ на наше недоумение архитектор признал, что процедура еще не документирована, тем самым предоставив нам повод зафиксировать риск. Впрочем, она компенсировалась нерискованным решением, которое мы сформулировали так: «Архитектура предусматривает простые и эффективные средства преобразования и миграции данных, значительно облегчающие размещение системы Nightingale». Магистральных рисков для Nightingale мы выделили всего три. 1. Избыточная зависимость от конкретных коробочных продуктов. В связи с этим мы сообщили о трудностях замены базы данных и исключения процессора правил» а также о зависимости от старой и (вероятно) более не поддерживаемой версии уровня переносимости базы данных. Данный магистральный риск представляет угрозу для коммерческого фактора удобства сопровождения. 2. Неполная определенность процесса восстановления после ошибок. Недостаточный уровень осведомленности заказчика о доступных инструментальных средствах. Некоторые сценарии касались обнаружения и устранения ошибок в базе данных. Несмотря на то что соответствующие процедуры были предусмотрены в архитектуре, о некоторых из них архитекторы и проектировщики задумывались впервые. Г1о словам представителей первого заказчика, процедур, направленных на исправление ошибок, у них не было (ни собственных, ни полученных от компании-разработчика). Этот магистральный риск ставил под сомнение реализацию коммерческого фактора практичности и обеспечения работы предприятия заказчика. 3. Вопросы, связанные с документацией. Документация проекта Nightingale оказалась в неудовлетворительном состоянии. К осознанию этого недостатка группа оценки пришла уже во время проводившегося перед первым этапом совещания, а сценарии, проанализированные на втором этапе, только утвердили нас в таком мнении. Несмотря на наличие ряда объемных и детальных элементов документации (построенной, в частности, средствами UML и модели Rose), ни вступительной части, ни обзора архитектуры составлено не было — а ведь без этого невозможно проводить подготовку персонала, внедрять в проект новых специалистов, сопровождать систему, координировать дальнейшую разработку и тестирование. Недокументированными также оставались обширная база правил, регламентировавшая поведение Nightingale, а также процедура преобразования и миграции данных. В отсутствие этой документации первый заказчик, уже готовый приобрести систему, не смог бы справиться с ее сопровождением; таким образом, риск распространялся на один из основных коммерческих факторов разработки Nightingale — обеспечение функционирования предприятия заказчика. Этап 3: доработка Осязаемым продуктом оценки по методу ЛТЛМ является сводный отчет с перечнем рискованных и нерискованиых решений, точек чувствительности и точек компромиссов. Помимо этого, в него включается каталог применяемых архитектурных методик, дерево полезности, сценарии, сформулированные методом мозгового штурма, и описание анализа всех отобранных сценариев. Наконец, в сводном отчете указываются магистральные риски, которые удалось выявить участникам группы оценки, и коммерческие факторы, реализацию которых они ставят под сомнение. Как и при презентации результатов, при составлении отчета мы воспользовались стандартным шаблоном, многие из разделов которого уже были заполнены (в частности, раздел, посвященный описанию метода АТЛМ); остальные нам лишь предстояло заполнить. Отдельные части сводного отчета — в частности, дерево полезности и результаты анализа операции 6 — мы подготовили во время перерыва между первым и вторым этапами. Все эти подготовительные действия привели к положительному результату: если раньше на подготовку сводного отчета для заказчика оценки АТАМ уходило около двух недель, то в рассматриваемом случае нам удалось составить качественный, комплексный отчет приблизительно за два дня. 11.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. Поскольку архитектурные стратегии ограничиваются разнообразными техническими и экономическими факторами, стратегии, применяемые программными архитекторами и проектировщиками, должны быть поставлены в зависимость от коммерческих задач программной системы. Прямой экономический фактор — это стоимость реализации системы. Техническими факторами являются характеристики системы — другими словами, атрибуты качества. У атрибутов качества также есть экономический аспект — выгоды, получаемые от их реализации. Как вы помните, по результатам оценки программной системы по методу АТАМ в нашем распоряжении оказался ряд документированных артефактов. ♦ Описание коммерческих задач, определяющих успешность системы. ♦ Набор архитектурных представлений, документирующих существующую или предложенную архитектуру.
♦ Дерево полезности, выражающее декомпозицию задач, которые заинтересованные лица ставят перед архитектурой, — от обобщенных формулировок атрибутов качества до конкретных
♦ Ряд выявленных рисков. ♦ Ряд точек чувствительности (архитектурных решений, которые оказывают влияние на отдельный показатель атрибута качества). ♦ Ряд точек компромиссов (архитектурных решений, которые воздействуют сразу на несколько показателей атрибута качества, причем на одни положительно, а на другие отрицательно). ATAM помогает выявить ряд основных архитектурных решений, значимых в контексте сформулированных заинтересованными лицами сценариев атрибутов качества. Эти решения приводят к реакции со стороны атрибутов качества — точнее говоря, отдельных уровней готовности, производительности, безопасности, практичности, модифицируемости и т. д. С другой стороны, каждое архитектурное решение связано с определенными издержками (стоимостью). К примеру, достижение желаемого уровня готовности путем резервирования аппаратных средств подразумевает один вид издержек, а регистрация в файлах на диске контрольных точек — другой. Эти архитектурные решения приводят к (предположительно разным) измеримым уровням готовности, имеющим определенную ценность для компании - разработчика системы. Возможно, ее руководство полагает, что заинтересованные лица заплатят большую сумму за систему с высокой готовностью (если, к примеру, это телефонный коммутатор или программное обеспечение для медицинского наблюдения), или боится погрязнуть в судебных разбирательствах в случае отказа системы (вполне разумно, если речь идет о программе управления антиблокировочной тормозной системой автомобиля). АТАМ обнаруживает архитектурные решения, принятые относительно рассматриваемой системы, и устанавливает их связь с коммерческими задачами и количественной мерой реакции атрибутов качества. Принимая эти данные на вооружение, СВАМ помогает выявить связанные с такими решениями издержки и выгоды. Основываясь на этой информации, заинтересованные лица могут принять окончательные решения относительно резервирования аппаратной части, введения контрольных точек и всех прочих тактик, направленных на повышение готовности системы. Вполне возможно, что они предпочтут сконцентрировать ресурсы, которые, как известно, ограниченны, на реализацию какого-то другого атрибута качества — например, на улучшение соотношения выгод и издержек за счет повышения производительности. Из-за ограниченности бюджета разработки и обновления системы каждое архитектурное решение, по большому счету, соревнуется за право па существование со всеми остальными. Подобно финансовому консультанту, который никогда напрямую не укажет, во что вкладывать деньги, СВАМ не заменяет собой решений, принимаемых заинтересованными лицами. Он лишь помогает им установить и документировать издержки и выгоды архитектурных инвестиций, осознать неопределенность этого «портфеля»; на этой основе заинтересованные лица могут принимать рациональные решения, удовлетворяющие их потребности и сводящие к минимуму риски. Короче говоря, метод СВАМ исходит из предположения о том, что архитектурные стратегии (как совокупность архитектурных тактик) оказывают влияние на атрибуты качества системы, а те, в свою очередь, предоставляют заинтересованным лицам некоторые выгоды. Эти выгоды мы называем полезностью (utility). Любая архитектурная стратегия отличается той или иной полезностью для заинтересованных лиц. С другой стороны, есть издержки (стоимость) и время, которые необходимо потратить на реализацию этой стратегии. Отталкиваясь от этой информации, метод СВАМ помогает заинтересованным лицам в процессе выбора архитектурных стратегий, характеризующихся максимальной прибылью па инвестированный капитал (return on investment, ROI), — другими словами, наиболее выгодных с точки зрения соотношения выгод и издержек. 12.2. Основы СВАМ Ниже мы рассмотрим, принципы, составляющие основу метода СВАМ. Их практическая реализация в виде последовательности этапов описывается в разделе 12.3. Предварительно вы должны разобраться с теоретической стороной расчета коэффициента ROI для различных архитектурных стратегий с учетом отобранных заинтересованными лицами сценариев. Для начала рассмотрим ряд сценариев, сформулированных в рамках АТАМ (или специально для оценки по методу СВАМ). Их следует исследовать на предмет различий по ценности предполагаемых реакций, а затем классифицировать полученные результаты по критерию полезности. Полезность определяется значимостью каждого рассматриваемого сценария с учетом предполагаемого значения реакции. Далее рассматриваются архитектурные стратегии, приводящие к различным предполагаемым реакциям. Каждая стратегия характеризуется издержками и воздействием на несколько атрибутов качества. Иначе говоря, архитектурная стратегия, которая изначально реализуется с целыо достижения желаемой реакции, попутно оказывает влияние на другие атрибуты качества. Полезность этих «побочных эффектов» необходимо учитывать при расчете общей полезности стратегии — ведь именно из общей полезности, прибавленной к проектной стоимости архитектурной стратегии, складывается окончательная величина ROI. Полезность При расчете полезности внимание обращается на проблемы, описанные в нижеследующих разделах.
Вариации сценариев По аналогии с АТАМ, сценарии в СВАМ применяются как механизм конкретного выражения и представления отдельных атрибутов качества. Так же как и в АТАМ, сценарии здесь разделяются на три части: стимул (взаимодействие с системой), условия (состояние системы в данный момент) и реакцию (результирующий атрибут качества, поддающийся количественной оценке). Впрочем, между упомянутыми методами есть и различия. В СВАМ, к примеру, сценарии задействуются целыми наборами (которые составляются путем варьирования значений реакции), в то время как АТАМ имеет дело с отдельными сценариями. Отсюда понятие кривой «реакция-полезность». Кривые «реакция-полезность» Каждая пара значений стимула-реакции в рамках сценария в какой-то степени полезна для заинтересованных лиц; более того, полезность возможных значений реакции можно сравнивать. К примеру, заинтересованные лица вряд ли оценят максимальную готовность в качестве реакции на отказ значительно выше, чем готовность умеренную. С другой стороны, низкая задержка, очевидно, имеет шансы на значительно более серьезную оценку по сравнению с умеренной задержкой. Любое отношение между набором величин полезности и соответствующим набором величин реакции можно выразить в виде графика, называемого кривой «реакция-полезность». Несколько примеров таких кривых приводятся на рис. 12.2. Точки с метками о, b и с на каждой из них выражают различные величины реакции. Таким образом, полезность на такой кривой изображается как функция от величины реакции. Кривая «реакция-полезность» демонстрирует изменение величин полезности в зависимости от изменения величин реакции. Как видим на рис. 12.2, полезность может изменяться линейно, нелинейно и ступенчато. К примеру, график (с) демонстрирует значительное повышение полезности при ограниченном изменении уровня реакции атрибута качества, что соответствует вышеприведенному примеру с производительностью. Пример с готовностью лучше сочетается с графиком (а), где умеренное изменение уровня реакции приводит к едва заметному изменению полезности для пользователя. Допытываться у заинтересованных лиц относительно характеристик полезности долго и утомительно. По этой причине для каждого сценария мы выбрали всего по пять значений реакции атрибута качества, посчитав, что приближенных величин будет вполне достаточно. Четыре из них универсальны для любых архитектурных стратегий, и о них мы поговорим прямо сейчас. Заметим лишь, что пятое значение, рассматриваемое далее по тексту, зависит от конкретной архитектурной стратегии.
Для того чтобы построить кривую «реакция-полезность», в первую очередь необходимо установить уровни атрибута качества в наилучшим и в наихудшем случаях. На уровне наилучшего случая атрибута качества заинтересованные лица усматривают максимальную полезность. К примеру, реакция системы на действия пользователя, происходящая за период времени в 0,1 с, воспринимается как мгновенная; таким образом, сокращение этого периода до 0,03 с бесполезно. Уровень наихудшего случая атрибута качества — это нижний предел, на котором система может функционировать; если он не соблюдается, в глазах заинтересованных лиц система теряет смысл. Эти уровни — наилучшего и наихудшего случая — соответствуют значениям полезности 100 и 0 соответственно.
Далее, для каждого сценария необходимо определить текущий (current) и желаемый (desired) уровни полезности. Значения полезности (находящиеся между 0 и 100) текущего и желаемого уровней определяются по показаниям заинтересованных лиц, причем значения наилучшего и наихудшего случаев используются как опорные точки (предположим, что в данный момент полезность считается 50-процентной, а желаемый уровень полезности атрибута качества находится на отметке 90 % максимально возможной полезности; соответственно, текущий уровень полезности приравнивается к 50, а желаемый — к 90). Таким способом кривые составляются для любых сценариев. Расстановка приоритетов среди сценариев Различные сценарии, сформулированные в рамках данной системы, имеют для заинтересованных лиц разную важность и, соответственно, характеризуются разной полезностью* Относительная значимость каждого сценария выражается через его вес (weight), назначаемый по результатам двухэтапной процедуры голосования. На первом этапе заинтересованные лица путем подачи голосов упорядочивают сценарии. Исходят они при этом из «предполагаемого» значения реакции. После этого заинтересованные лица присваивают наиболее приоритетному сценарию вес 1, а всем остальным, в зависимости от их относительной значимости» дробные значения. Если в какой-то момент в будущем появится потребность во введении новых сценариев, им также нужно будет присвоить значение веса. Совещательным путем заинтересованные лица приводят значения веса в согласие со своими представлениями. Архитектурные стратегии В обязанности архитектора (или архитекторов) входит выбор архитектурных стратегий, позволяющих перейти от текущего уровня реакции атрибута качества к желаемому или даже наилучшему. Специально для этой цели н рамках СВЛМ существует отдельный этап. Для каждой стратегии выводятся:
|