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

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

Операция 5: генерация дерева полезности атрибутов качества

Дерево полезности, составленное во время проверки системы Nightingale по ме­тоду АТАМ, представлено в табл. 11.5. Обратите внимание — на нем присутству­ют все атрибуты качества, установленные в ходе операции 2; более того, они уточ­нены до одного или нескольких конкретных значений.

Некоторые уточнения атрибутов качества остались без связанных сценариев.

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

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

¹ Кроме того, мы пробовали составлять деревья полезности к оперативном режиме — заполняли таб­лицы, подобные табл. 11.5, и проецировали их непосредственно с компьютера. При таком подходе дерево легче составлять и корректировать, однако доступным для просмотра участниками остается содержание одного-сдинственного экрана. В то же время обзор дерева во всей его полноте стимули­рует умственную деятельность и помогает находить бреши. Программные системы для совместной работы будто бы идеально подходят для подобных ситуации, однако по простоте, надежности и эко­номичности им сложно тягаться с лекционными плакатами и клейкой лентой.

Таблица 11.5, Дерево полезности, составленное в ходе оценки системы Nightingale по методу АТАМ, в табличном выражении

Атрибут качества Уточнение атрибута	Сценарии
Производитель­	Время отклика	В ответ на уведомление о смене адреса при пиковой
ность	на транзакцию	нагрузке на систему пользователь обновляет учетную запись пациента; транзакция завершается менее чем за 0,75 секунды (В,С) В ответ на уведомление о смене адреса при нагрузке на систему, в два раза превышающей текущую пиковую, пользователь обновляет учетную запись пациента; транзакция завершается менее чем за 4 секунды (Н,С)
	Пропускная	При пиковой нагрузке системе удается проводить
	способность	150 нормализованных транзакций менее чем за секунду (С,Н)
	Составление отчетов	Предложений по сценариям не последовало
Практичность	Повышение	Новый сотрудник с одним или двумя годами опыта
	квалификации	работы в отрасли осваивает базовые функции системы менее чем за неделю (С,Н) Пользователь, находясь в определенном контексте, запрашивает справку и получает ее (В,Н)
	Нормальный режим	Больничный кассир запускает для пациента,
	работы	с которым одновременно общается, план выплат; процесс завершается без каких-либо задержек по вине системы (С,С)
Конфигуриру­		Больница повышает цену на отдельную услугу.
емость		Группа конфигураторов вносит в систему соответствующие изменения, затрачивая не более одного рабочего дня и не затрагивая исходный код (В,Н)
Удобство		Обнаружив недостатки, связанные с поиском
сопровождения		и временем отклика, специалист по сопровождению исправляет ошибку и распространяет исправление ------------------------------------ продолжение

Таблица 11.5 (продолжение)

Атрибут качества	Уточнение атрибута Сценарии
	Требование по отчетности подразумевает внесение изменений в метаданные составления отчетов (С.Н) Производитель базы данных выпускает ее новую версию, на установление которой затрачивается минимальное количество времени (В,С)
Расширяемость	Введение нового Создается новый продукт, отслеживающий доноров продукта банка крови (С,С)
Безопасность	Конфиденциальность Полномочия физиотерапевта позволяют ему просматривать содержимое регистрационной карточки пациента, связанное с ортопедическим лечением; остальные элементы карточки, равно как и финансовая информация, для него закрыты (В,С) Целостность Система успешно противостоит попыткам несанкционированных вторжений (В,С)
Готовность	Выпущенное производителем баз данных новое программное обеспечение вводится в систему методом горячей замены (В,Н) Система обеспечивает возможность ежедневного круглосуточного доступа пациентов к своим учетным записям через Интернет (Н,Н)
Масштабиру­	Расширение системы Первый заказчик системы приобретает компанию,
емость	масштаб которой превышает его собственные показатели в три раза; при этом требуется провести разбиение базы данных (Н,В) Первый заказчик системы продает другой компании одно из своих подразделений (Н,С) Первый заказчик системы проводит слияние двух своих подразделений (Н,С) Компания-разработчик желает продать ряд компонентов системы Nightingale (С,Н)
Модульность	Функциональные Требуется сконструировать систему таким образом, подмножества чтобы она могла работать автономно и при этом предоставлять свою базовую функциональность (С,Н) Гибкость в отношении Замена коммерческой базы данных одного замены коробочных производителя коммерческой базой данных другого продуктов производителя (В,С) Замена операционной системы (В,С) Замена уровня переносимости базы данных {В,С) Замена диспетчера транзакций (В,С) Замена механизма автоматизации документооборота (В,С) Замена коммерческого бухгалтерского пакета (В,С) Замена базы данных Solaris, размещенной на платформах Sun (В,С) Замена процессора правил (В,С)

Атрибут качества Уточнение атрибута	Сценарии
Способность	Требуется реализовать в системе интерфейс
к взаимодействию	с эпидемиологической базой данных,
	размещенной в нескольких национальных
	центрах контроля заболеваний (С,С)
Контролепригодность
Удобство поддержки

Сценарии в табл. 11.5 сопровождаются указанием приоритетов, распределен­ных участниками из числа ответственных лиц. В каждой упорядоченной паре символ до запятой обозначает значимость соответствующей возможности; сим­вол после запятой отражает оценку архитектора относительно сложности ее реа­лизации.

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

Операция 6: анализ архитектурных методик

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

Вместе с архитектором мы проработали несколько сценариев. На каждый ушло в среднем полчаса^[4]. Поскольку все они оказались связаны с внесением измене­ний, мы резонно поинтересовались их диапазоном и воздействием. Выяснили мы следующее.

♦ Замена одной коммерческой базы данных другой, приобретенной у нового производителя, обещала стать трудным занятием. В масштабе всей систе­мы использовался один из диалектов SQL (надмножество SQL по стандар­ту ANSI), специфичный для производителя текущей базы данных, а также ряд не менее специализированных инструментов и компонентов. По мне­нию архитектора, замена базы данных была бы крайне маловероятна, в связи

с чем он не брал в расчет высокую стоимость перехода на новую систему. Впрочем, руководитель проекта не выказал столь же твердой уверенности в невозможности развития событий по рассматриваемому сценарию. Таким образом, мы зафиксировали первый установленный на основе анализа ар­хитектурный риск: «Поскольку в системе Nightingale используются специ­фичные для конкретного производителя инструменты и компоненты, а также диалект SQL не поддерживаемый или несовместимый с базами данных других производителей, произвести замену базы данных будет очень слож­но и отнюдь не дешево — весь процесс займет несколько человеко-лет». Архитектурное решение о связывании архитектуры с конкретной базой дан­ных мы обозначили как точку чувствительности с отрицательным воздей­ствием на модифицируемость.

♦ Заменить одну операционную систему другой было бы довольно просто. На стороне сервера операционная система была выделена на отдельный уровень, что способствовало локализации изменений. С другой стороны, подсистема OLTM напрямую зависела от средств аутентификации NT, а значит, от новой операционной системы требовались аналогичные свой­ства. Что касается DSRGM, то здесь все зависимости от операционной си­стемы были исключены на уровне исходного кода — дело в том, что разра­ботка этой подсистемы проводилась на платформе Windows NT, а размещена она была на платформе UNIX; отсюда очевидный вывод о ее полной неза­висимости от операционной системы. В связи с этим мы зафиксировали первое нерискованное решение: «Поскольку зависимости от операционной системы в подсистемах OLTM и DSRGM локализованы или исключены, введение новой операционной системы вместо старой не предполагает сколь­ко-нибудь серьезных модификаций». Инкапсуляцию зависимостей от опе­рационной системы мы отметили как точку чувствительности с положи­тельным воздействием на модифицируемость.

♦ Мы установили ряд проблем, связанных с внесением изменений в процес­сор правил. Считать такой сценарий надуманным нет никаких оснований — как мы выяснили, текущий процессор не отличался высокими характерис­тиками производительности и удобства сопровождения. Вероятнее всего, впоследствии его бы просто исключили, а правила реализовали бы сред­ствами C++. Поскольку прямое построение цепочек правил не разрешалось (что было вполне разумно и объяснялось желанием отложить соответству­ющее решение на более поздний период), правила в силу их процедурного характера можно было скомпилировать. Подобная модификация, скорее всего, привела бы к нескольким серьезным последствиям.

- Повышение производительности (хотя бесспорного решения эта проб­лема на тот момент еще не получила).

- Устранение необходимости в обучении сотрудников языку правил и объ­яснению им принципа действия процессора.

- Группе разработчиков не пришлось бы создавать полезные правила и сре­ду моделирования.

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

- Возможность размещения в правилах ссылок на несуществующие объек­ты, вероятно, удалось бы исключить. В современном варианте эта воз­можность, обусловливавшая возникновение ошибок, существовала и имела серьезные шансы, просочившись через тестирование, попасть в произ­водственную систему. Путем составления правил средствами C++ по­добные ошибки можно было бы устранить уже в период компиляции.

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

И так далее. Впоследствии, в рамках того же сценария, мы проанализировали замену коммерческого блока веб-хостинга, коммерческого бухгалтерского паке­та, механизма автоматизации документооборота и операционной системы Solaris на платформах Sun,

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

Этап 2: оценка (продолжение)

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

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

В первую очередь, специально для новых участников, мы повторили первую операцию (описание метода АТЛМ), а для того чтобы привести знания всех при­сутствующих к единому знаменателю, рассказали о результатах первого этапа. После этого мы приступили к выполнению операций 7, 8 и 9.

Операция 7: мозговой штурм и расстановка сценариев согласно приоритетам

Заинтересованные лица поработали на славу — всего в ходе этой операции о*ни огласили 72 сценария. Более десятка из них были отражены на листьях дерева полезности, которое мы составили во время операции 5, но на первом этапе до их анализа дело не дошло. Это вполне нормально, даже полезно. Таким способом заинтересованные лица давачи нам понять, что некоторые сценарии заслужива­ют большего внимания, чем то, которое они получили на первом этапе.

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

Таблица 11.6. Сценарии, полученные методом мозгового шторма  

Номер	Сценарий
	Данные, ранее бывшие общедоступными, сделаны приватными; соответствующие изменения внесены в права доступа
	Данные, взятые из информационного ядра, сдублированы в одном из отделений клиники, в результате чего снизилась производительность
	При запуске правила в процессоре доступ к данным осуществляется слишком медленно
	Пользователь регистрирует проведенный пациентом платеж в момент сильной загрузки системы, в результате чего замедляется реакция (происходит это в тестовой среде)
	Пользователю, находящемуся в одном подразделении, требуется выполнить операции от имени других подразделений
	Принято решение о поддержке немецкого языка
	В систему вводится роль эпидемиолога и соответствующая функциональность
	Система Nightingale устанавливается в кабинете с пятью врачами и адаптируется под условия заказчика
	Для подачи асинхронных запросов пользователю требуется новое поле
	Получив жалобу, сотрудники больницы обнаруживают, что на протяжении последних шести месяцев подкладываемые судна оценивались неверно
	Больнице требуется централизовать процесс обслуживания регистрационных карточек в масштабе нескольких отделений; при этом все сопутствующие бизнес-процессы подвергаются реконструкции
	Менеджер хочет составить отчет по истории просроченных платежей и пеням, выставленным пациентам, проходившим лечение от порезов и ран
	«Условный» (what-if) сценарий: Приложение к учетной записи предполагаемой поправки в закон
	Дефект, приведший к искажению данных, не удалось обнаружить до следующего цикла отчетности

Номер	Сценарий
	При установке системы Nightingale в больнице необходимо преобразовать существующую в ней базу данных
	В результате ошибки в процессе репликации база данных транзакций рассинхронизируется с резервной базой данных
	Системная ошибка приводит к невозможности зачисления платежей на счета, находящиеся в Аризоне
	Контрольный журнал транзакций не пополняется на протяжении трех дней (как исправить ошибку?)
	Одно из отделений меняет продолжительность рабочего дня и месяца
	Получение информации о зачислении платежа от системы управления базами данных страховой компании (при помощи определения метаданных)
	Введение нового технологического процесса входной и выходной регистрации пациентов
	Пакетные процессы инициируются на временной и событийной основах
	Неисправность главной магистрали передачи данных от информационного ядра к филиалам клиники
	Сервер базы данных одного из отделений клиники не загружается
	При составлении отчета требуется получить информацию из двух больниц, в каждой из которых используется индивидуальная конфигурация
	Центр денежных переводов дважды подает одну и ту же группу платежей, причем операции начинаются только после второй подачи
	Терапевт, специалист по реабилитации, переводится в другую больницу; при этом ему требуется доступ к историям болезни бывших пациентов с полномочиями чтения
	Согласованное распределение ряда изменений среди нескольких узлов в учреждениях здравоохранения (формы и конфигурации)
	В результате пожара в информационном центре информационное ядро приходится перевести в другое место
	Больница переуступает большое количество счетов, выставленных на другое подразделение
	Изменение правил составления предупреждений о взаимоисключающих лекарственных препаратах
	Пользователь в бухгалтерии больницы хочет перейти из режима распечатки выходных данных в режим их оперативного просмотра
	Телефонная компания меняет междугородный телефонный код
	Администратор счетов предумышленно перевел с них небольшие суммы на счета своих друзей. Как выявить нарушителя и определить масштаб злоупотреблений?

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

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

Дата добавления: 2015-04-25