Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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




 

Затраты (стоимость) оценки выражаются во времени, затраченном на эту проце­дуру специалистами. Имея опыт критического анализа приблизительно 300 пол­ноценных вариантов архитектуры для проектов, на разработку которых уходит как минимум 700 человеко-дней, компания AT&T, по данным своих руководите­лей проектов, называет средние затраты на оценку — 70 человеко-дней. Проведение критического анализа по методике АТАМ занимает примерно 36 человеко­дней (Этот показатель учитывает только работу группы оценщиков. Поскольку методика АТАМ предполагает участие в оценке заинтересованных лиц и ответственных лиц, общие затраты увеличиваются.). Если в вашей компании на постоянной основе существует подразделение, занимающееся исключительно оценкой, при расчете затрат следует учитывать стоимость его содержания, а также временные затраты на обучение сотрудников.

Выгоды

Нам известны шесть видов преимуществ, связанных с обследованием архитектуры.

1. Финансовые преимущества. В AT&T руководитель каждого проекта обязан сделать приблизительный расчет средств, которые можно сэкономить пу­тем оценки архитектуры. Согласно средним за восемь лет деятельности показателям, комплексная архитектурная оценка любого проекта уменьша­ет стоимость проекта на 10 %. Учитывая то, что на оценку уходит в среднем 70 человеко-дней, окупается оценка тех проектов, работа над которыми продолжается 700 человеко-дней и дольше.

Мы не располагаем сопоставимыми количественными данными других компаний. Однако, по словам некоторых консультантов, более 80 % их ра­боты — это повторение уже выполненных задач. Их клиенты довольно быстро осознали, что дополнительное проведение оценки просто выгодно.

Случаев, когда в результате оценки заказчики смогли избавить себя от лиш­них трат, известно множество. Рассказывают, например, что одна крупная компания отказалась от многомиллионного контракта, узнав, чго архитек­тура глобальной информационной системы, которую она планировала при­обрести, не способна реализовать желаемые атрибуты качества. Проведен­ный на раннем этапе архитектурный анализ электронной системы перечис­ления денежных средств показал, что предоставляемая ею суточная ем­кость в $50 миллиардов в два раза меньше предполагаемой. Оценка систе­мы розничной торговли выявила проблемы производительности самого высокого порядка, справиться с которыми не смогли бы даже самые совер­шенные аппаратные средства. Таким образом, заказчик сумел предотвра­тить собственное банкротство. И так далее.

Рассказывают также и о том, к каким неприятностям приводит игнориро­вание процедуры оценки. В одном таком случае пересмотр системы учета клиентов планировалось провести за два года, однако по прошествии семи лет она претерпела целых три повторных реализации. Несмотря на то что вычислительная мощность в последней версии в 60 раз превосходила ха­рактеристики первоначального макета, удовлетворить требования по про­изводительности так и не удалось. В другом случае проблемы с производи­тельностью, обусловленные непродуманными проектными решениями, сде­лали невозможным компонентное тестирование. В результате проект — разработку крупной инженерной системы реляционных баз данных — свер­нули. Обошелся этот грандиозный успех в $20 миллионов.

 

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

3. Фиксация логического обоснования. В процессе оценки архитектуры внима­ние всегда заостряется на нескольких областях; перед оценщиками ставят­ся вполне конкретные вопросы. Для того чтобы на эти вопросы можно было ответить, часто требуется получить представление о проектных реше­ниях и соответствующих логических обоснованиях. Документация логи­ческого обоснования проекта оказывается востребованной на дальнейших стадиях жизненного цикла, помогая оценить эффект модификаций. Задо­кументировать логическое обоснование постфактум невероятно сложно. Его фиксация по результатам оценки архитектуры, таким образом, приносит немалую пользу впоследствии.

4. Своевременное выявление недостатков существующей архитектуры. Чем раньше проблемы обнаруживаются, тем дешевле их исправить. В частности, по результатам оценки архитектуры возможно выявление проблем, связан­ных с необоснованными (или слишком дорогостоящими в части реализации) требованиями, производительностью или потенциальными нисходящими модификациями. Оценка сценариев модификации системы способствует обнаружению трудности переносимости и расширяемости. Таким образом, оценка архитектуры помогает составить представление о возможностях и ограничениях продукта на ранней стадии его проектирования.

5. Проверка требований. Проверка соответствия архитектуры предъявляемым к ней требованиям перетекает в анализ требований как таковых. Это помо­гает лучше уяснить их суть и (как правило) расставить приоритеты. Про­цесс формулирования требований, проводящийся в отрыве от ранних ста­дий проектирования, обычно приводит к конфликту свойств системы. Высокая производительность, безопасность, отказоустойчивость, низкие затраты — всего этого легко потребовать, но крайне проблематично (а иногда и невозможно) достичь. Оценка архитектуры вскрывает конфликты, ука­зывает на возможные компромиссные решения и создает условия для со­вместного обсуждения возникших проблем.

6. Усовершенствование ароситектуры. Компании, встроившие оценку архитек­туры в стандартный процесс разработки, отмечают повышение качества результата. Предугадывая возможные вопросы и предметы для обсужде­ния, зная, какая документация потребуется для оценки архитектуры, ком­пании-разработчики естественным образом увеличивают эффективность проведения этой процедуры. Результатом становится повышение качества архитектуры, наблюдаемое не только после оценки, но, по существу, и до ее проведения. Со временем компания вырабатывает культуру качественного архитектурного проектирования.

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

Методики

Рассматриваемые в двух последующих главах методы АТАМ и CBAM являют собой примеры вопросных методик (questioning techniques). Они предполагают формулирование испытательных вопросов согласно сценариям и проверку реак­ции оцениваемой архитектуры на различные ситуации. Среди других вопросных методик следует упомянуть контрольные списки и анкеты. Эффективными они оказываются в тех случаях, когда оценщикам приходится работать с однотипны­ми системами, каждый раз организуя для них одни и те же испытания. Все во­просные методики, по сути, основываются на мысленных экспериментах, и с их помощью определяют степень соответствия гой или иной архитектуры постав­ленным задачам.

Естественным дополнением вопросных методик являются измерительныеме* тодики (measuring techniques). Они опираются на количественные показатели. В качестве примера таковой можно привести архитектурные метрики. По резуль­татам измерений сцепления в рамках архитектуры, связности ее модулей или глубины иерархии наследования можно сделать определенные выводы о моди­фицируемости результирующей системы. К измерительным методикам также относятся приемы, предполагающие проверку на предмет интересующих атрибу­тов качества (например, атрибутов периода прогона наподобие производительно­сти или готовности) моделей и макетов.

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

Планировать или не планировать?

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

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

Незапланированная проверка для участников проекта — это, напротив, насто­ящее испытание. Она требует выделения дополнительных временных ресурсов, которых и так не хватает. Решение о проведении незапланированной проверки принимается руководством в случае высокой вероятности неблагоприятного ис­хода и, таким образом, воспринимается как средство внесения промежуточных корректив. Незапланированные проверки носят реактивный характер и прово­дятся в довольно напряженной атмосфере. Руководитель группы оценщиков обязан не допустить выяснения отношений между своими подчиненными.

Не стоит и говорить, что запланированные оценки предпочтительнее.

Предварительные условия

Об успехе процедуры оценки можно судить по следующим критериям:

1. Четко сформулированные задачи и требования к архитектуре. Оценивать полезность архитектуры можно только в контексте определенных атрибу­тов качества. Система, отличающаяся сверхпроизводительностью, может оказаться совершенно непригодной для выполнения задач, требующих модифицируемости. Анализировать архитектуру, не разобравшись с крите­риями «добротности», — все равно что отправляться в путь куда глаза гля­дят. Иногда (хотя, судя по нашему опыту, крайне редко) эти критерии уста­навливаются в форме спецификации требований. Более вероятно, что их определение придется на период перед оценкой или непосредственно на оценку. Задачи определяют цель оценки; их следует явно оговаривать в до­говоре об оценке и уточнять впоследствии.

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

3. Экономическая эффективность. Организаторы оценки обязаны убедиться в том, что выгоды от проведения проверки (с высокой вероятностыо) пре­высят затраты. Те виды оценки, о которых мы говорим, нодходяг для про­ектов среднего и крупного масштаба, однако их эффективность в отноше­нии малых проектов весьма сомнительна.

4. Наличие необхоЪимых специалистов. К проведению проверки совершенно необходимо привлечь архитектора или другого специалиста, способного авторитетно рассуждать об архитектуре и проектировании. Этот человек (или эти люди) должен уметь сжато и ясно изложить факты архитектуры и мотивацию принятия архитектурных решений. Если речь идет об очень крупной системе, необходимо участие проектировщиков ее основных ком­понентов — они должны проверить, насколько сложившееся у архитектора представление об архитектуре фактически отражено на более детальных уровнях. Проектировщики, кроме того, могут сообщить немало важного об атрибутах поведения и качества компонентов. В контексте методики АТАМ следует обеспечить участи^ в оценке архитектуры заинтересованных лиц. Необходимо определить лиц, желающих получить отчет об оценке, устано­вить их приоритеты и ожидания.

5. Квалифицированность группы оценщиков. В идеале, оценкой программной архитектуры должно заниматься специальное подразделение компании. Участники группы оценщиков должны быть беспристрастны, объективны и уважаемы. Группа должна создавать впечатление компетентности в сво­ей области; результаты ее деятельности должны иметь определенное значе­ние в глазах других специалистов — иначе они неизбежно будут восприни­мать ее функции как бесполезные. В группе оценщиков должны работать люди, смыслящие в вопросах архитектуры, а во главе ее должен стоять специалист, имеющий серьезный опыт проектирования и оценки проектов на архитектурном уровне.

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

Результаты

По результатам оценки следует составить отчет, охарактеризовать в нем все вы­явленные проблемы и подкрепить выводы фактами. Черновик отчета следует передавать поочередно каждому из оценщиков; совместно они должны устранить из него все недоразумения, любую необъективность, сопоставить различные эле­менты и только после этого составить окончательный вариант. В идеале, если те или иные проблемы не решаются, их следует ранжировать по принципу потенци­ального влияния на проект. Также следует собирать информацию о самом про­цессе оценки. На основе совокупных данных о ряде оценок можно выстроить специальные методики, выработать способы обучения, наконец, усовершенство­вать процессы разработки системы в целом и оценки архитектуры в частности. Необходимо анализировать затраты и выгоды проведения оценки. Информацию о предшествующих процедурах оценки компания должна использовать, во-пер­вых, для внесения корректив в последующие подобные процедуры и, во-вторых, для составления аналитических сводок по затратам и выгодам.

Внастоящей части три главы. Метод АТАМ (рассматриваемый вглаве 11) представляет собой структурный метод оценки архитектуры. По результатам его применения составляется список рисков несоответствия архитектуры предъяв­ленным к ней требованиям. CBAM (глава 12) — это метод ранжирования рисков. В крупных системах зачастую оказывается слишком много рисков. Решение о том, какой из них следует сгладить в первую очередь, необходимо принимать исходя из сопоставления затрат модифицирования архитектуры, без которых этот риск не сгладить, и выгод его сглаживания. В методе CBAM предусматривается струк­тура, направленная на решение этой организационно-экономической задачи. В гла­ве 13 приводится очередной конкретный пример систем, ориентированных на WWW. Их развитие рассматривается как прохождение нескольких архитектур­но-экономических циклов.

Дополнительная литература

Изложенный в этом введении материал взят из исследования [Abowd 96] «Recom­mended Best Industrial Practice for Architecture Evaluation», составленного по ре­зультатам семинаров, проведенных его авторами и другими научными сотрудни­ками Института программной инженерии. На них побывали представители восьми промышленных и консультативных компаний.

Методика архитектурной оценки на основе контрольных списков и анкет — одна из разновидностей активного анализа проектного решения (active design review) — изложена в работе [Parnas 85b]. Активная оценка проектного решения предполагает участие нескольких лиц, которые, основываясь на документации, отвечают на заранее подготовленные вопросы. Этот метод заметно отличается от случайной и неорганизованной оценки, участники которой докладывают об от­клонениях по мере их обнаружения.

В издании [Cusumano 95] метрики рассматриваются как средство выявления мест, в которых с наибольшей вероятностью могут произойти изменения.

Богатый опыт по части оценки вариантов архитектуры, накопленный компа­нией AT&T, обобщается в работе [AT&T 93].


 

Глава 11

Метод анализа компромиссных архитектурных решений — комплексный подход к оценке архитектуры

(в соавторстве с Марком Кляйном)

06 услугах, которые нам оказывают другие люди, мы судим по тому, насколько существен­ными они кажутся им, а на действительную их ценность как-то не обращаем внимания.

Фридрих Нище

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

Оценить архитектуру крупной системы весьма не просто. Во-первых, чем боль­ше система, тем масштабнее ее архитектура и тем протяженнее промежуток вре­мени, за который о ней можно составить некое представление. Во-вторых, соглас­но Ницше (см. эпиграф) и архитектурно-экономическому циклу (Architecture Business Cycle, ABC), любая компьютерная система призвана решать коммерческие зада­чи; таким образом, и ходе оценки необходимо устанавливать связи между этими задачами и техническими решениями. Наконец, крупные системы, как правило, характеризуются многочисленностью заинтересованных лиц, а для того чтобы за ограниченный промежуток времени проанализировать их позиции, процесс оценки ш'обходпмо внимательно контролировать. Итак, из всего вышесказанного понят­


но, что основной проблемой в контексте оценки архитектуры является ограни­ченность по времени.

Основное назначение АТАМ состоит в том, чтобы выявить коммерческие за­дачи, поставленные в контексте разработки системы и проектирования архитек­туры. Вкупе с участием заинтересованных лиц это помогает специалистам по оценке сфокусироваться на тех элементах архитектуры, которые играют перво­степенную роль для реализации упомянутых задач.

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

11.1. Участники АТАМ

Ниже перечислены группы специалистов, участие и сотрудничество которых яв­ляется необходимым условием проведения процесса АТАМ.

1. Группа оценки. Специалисты из этой группы не должны участвовать в раз­работке оцениваемой архитектуры. Как правило, численность группы со­ставляет 3-5 человек. Каждому из них назначается ряд ролей, которые он должен исполнять в период оценки. (Описание этих ролей, а также жела­тельные характеристики каждой из них приводятся в табл. 11.1.) В некото­рых случаях группа оценки являет собой постоянное подразделение, регу­лярно проводящее действия по оценке вариантов архитектуры; в иных ситуациях ее участники подбираются из числа специалистов с серьезными знаниями в области архитектуры для выполнения конкретной задачи. Иногда группы оценки и разработки набираются из сотрудников одной компании, однако не исключается вариант заказа оценки у третьей сторо­ны. В любом случае это должны быть компетентные, объективные люди без предубеждений и корыстных целей.

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

3. Заинтересованные в архитектуре лица. Заинтересованным лицам, естествен­но, хочется, чтобы архитектура не отклонялась от проекта. Способность этих людей выполнять свои задачи напрямую зависит от того, в какой сте­пени архитектура реализует модифицируемость, безопасность, высокую надежность и прочие атрибуты качества. В число заинтересованных лиц входят разработчики, тестировщики, сборщики, специалисты по сопровож­дению, инженеры по эффективности, пользователи, конструкторы систем, взаимодействующих с рассматриваемой системой, и многие другие. В ходе оценки от них требуется сформулировать конкретные задачи по реализа­ции атрибутов качества, при выполнении которых систему можно будет признать удачной. Нормальным следует считать участие в процессе оцен­ки 12-15 заинтересованных лиц.

Таблица 11.1. Распределение ролей между участниками группы оценки[1]
Роль Обязанности Предпочтительные характеристики
Руководитель Планирует оценку; общается Организованность,
группы с заказчиком и гарантирует управленческие способности,
  выполнение его требований; утверждает навыки ведения переговоров
  договор о проведении оценки; набирает с заказчиком, выполнение
  специалистов в группуоценки; обязанностей в установленные
  координирует составление и предоставление заказчикусводного отчета (обязанности по его составлению можно делегировать) сроки
Руководитель Ответствен за проведение оценки; Способность выступать перед
специалистов содействует выявлению сценариев; аудиторией; развитые навыки
по оценке координирует отбор сценариев и их содействия; компетентность
  классификацию согласно приоритетам; в вопросах архитектуры; опыт
  содействует процессу оценки сценариев участия в оценке вариантов
  в контекстеархитектуры; содействует архитектуры; способность
  проведению местного анализа отличить беспредметные прения от дискуссии, потенциально ведущей к получению ценных выводов
Секретарь В процессе выявления сценариев Хороший почерк; способность
по сценариям пишет сценарии на лекционном сосредоточивать специалистов
  плакате или белой доске; фиксирует на задаче формулирования идеи
  согласованные формулировки (сценария); понимание
  сценариев; не позволяет остальным технической терминологии
  участникам углубляться в дискуссии и способность резюмировать
  до получения точных формулировок соответствующие дискуссии
Секретарь по Работая на портативном компьютере Крепкие навыки быстрого
результатам или на рабочей станции, в электронной клавишного набора; способность
  форме фиксирует результаты: оперативно восстанавливать
  непроверенные сценарии, соображения, в памяти нужную информацию;
  влияющие на их составление компетентность в архитектурных
  (во многих случаях они не отражаются вопросах; навыки быстрого
  в формулировкесамогосценария), усвоения технических проблем;
  резолюции сценариев применительно отсутствие комплексов,
  к архитектуре; в его обязанности также позволяющее(в подходящий
  входит предоставление всем участникам момент) прервать дискуссию для
  печатной версии списка всех принятых прояснения вопроса и фиксации
  сценариев нужной информации

[1] Источник: приводится no изданию [Clcmcnts 02a] (адаптированная версия).

 

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

 

11.2. Результаты проведения оценки по методу АТАМ

Минимальный набор результатов процесса оценки на основе АТАМ выглядит следующим образом.

♦ Компактная презептацггя архитектуры. Согласно распространенному мне­нию, документация архитектуры не может обойтись без объектной модели, списка интерфейсов и их сигнатур или какого-нибудь другого объемистого перечня. Одно из требований, предъявляемых к документации методом АТАМ, напротив, подразумевает возможность ее составления за один час; получившаяся в результате архитектурная презентация должна быть, та­ким образом, краткой и понятной (хотя как раз понятной она бывает не всегда).

♦ Формулировка коммерческих задач. Часто бывает так, что отдельные участ­ники группы разработчиков впервые узнают о коммерческих задачах имен­но из презентации АТАМ.

♦ Требования по качеству в форме совокупности сценариев. Коммерческие задачи подразумевают формулирование требовании по качеству Некото­рые из них фиксируются в форме сценариев.

♦ Отображение apxuтектурных решений на требования по качеству. Архи­тектурные решения можно интерпретировать исходя из тех атрибутов ка­чества, реализации которых они способствуют или препятствуют. Для каж­дого анализируемого по методу АТАМ сценария реализации атрибута качества определяются те архитектурные решения, которые помогают его реализовать.

♦ Ряд установленных точек чувствительности и компромиссов. Так называ­ются архитектурные решения, оказывающие заметное воздействие на один или несколько атрибутов качества. К примеру, решение о введении резерв­ной базы данных, очевидно, относится к числу архитектурных, — оказывая положительное воздействие на надежность, в отношении этого атрибута качества оно является точкой чувствительности. С другой стороны, на со­провождение резервной базы данных расходуются системные peqypcbi, а зна­чит, это решение отрицательно сказывается на производительности. Сле­довательно, оно одновременно является точкой компромисса между надежностью и производительностью. Признать его рискованным или, на­против, не связанным с рисками, можно только исходя из оценки стоимо­сти производительности в контексте предъявляемых к данной архитектуре требований по атрибутам качества.




Поделиться с друзьями:


Дата добавления: 2015-04-25; Просмотров: 525; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.051 сек.