Главная / Менеджмент / Архитектурное проектирование программного обеспечения

Архитектурное проектирование программного обеспечения - ответы на тесты Интуит

Правильные ответы выделены зелёным цветом.
Все ответы: Рассматриваются вопросы разработки инновационных подходов к созданию и документированию архитектуры программного обеспечения.

Смотрите также:

Программирование

В основе архитектурного проектирования лежат понятия:

(1) Проектирование – как средство достижения поставленного результата

(2) Архитектура – как результат

(3) Архитектура – как видение

(4) Проектирование – как инструмент планирования разработки

Архитектурное решение зависит от следующих факторов

(1) Наличие свободных ресурсов; Поддержка спонсоров проекта

(2) Сроков проекта; Проектной команды

(3) «Внешнее окружение» архитектуры программного продукта; «Внутренние» используемые архитектурные компоненты и связи между ними

(4) Понятность и прозрачность требований к архитектуре программного продукта; Желаемые характеристики архитектуры

Перед тем как внедрять стандарты в процессы конкретной организации следует

(1) Достичь определенного уровня зрелости процессов компании

(2) Отказаться от других стандартов

(3) Адаптировать их под реалии конкретной организации

(4) Оценить возможность обеспечения поддержки стандартов

Под уровнями архитектуры программного обеспечения понимаются

(1) Стадии разработки продукта

(2) Модели проектирования разрабатываемой информационной системы

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

(4) Модели порядка и синхронизации исполнения бизнес-процессов

Чтобы не допустить устаревания программного продукта и адекватно реагировать на запросы бизнеса, компания должна иметь:

(1) Высококвалифицированный персонал

(2) Поддержку вендора

(3) План развития

(4) Необходимые ресурсы

Архитектурное проектирование программного обеспечения, одной из задач ставит

(1) бесперебойное функционирование информационных систем компании

(2) поддержку и развитие существующих процессов и информационных систем компании

(3) формирование особого видения, всех участников проекта, на конечный продукт

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

Признаком успешной архитектуры является

(1) Стабильность

(2) Простая видоизменяемость

(3) Производительность

(4) Многофункциональность

Степень влияние информационных технологий на поддержку и развитие бизнеса определяет

(1) Инновационность компании и степень участия в инновациях информационных технологий

(2) Потенциальный размер прибыли компании

(3) Состав и квалификацию руководства компании

(4) Управленческие процессы компании

Каждый уровень и дисциплина детализируются настолько подробно

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

(2) Насколько определено используемым стандартом

(3) Насколько требуют управляющие органы

(4) Насколько позволяет уровень компетентности персонала

Архитектурная роль "Architectus Oryzus" описывается Мартином Фаулером как:

(1) человек, осведомлённый обо всём, что происходит в проекте, следящий за всеми трудностями, помогающий предвидеть и объяснять технические последствия нетехнических идей и требований;

(2) системный архитектор, выполняющий роль менеджера проекта

(3) сотрудник-руководитель, принимающий большинство важных решений в процессах жизненного цикла программного продукта и поддерживающий концептуальную целостность системы

(4) самая важная роль в процессах архитектурного проектирования программного продукта

В процессе архитектурного проектирования важно сделать выбор

(1) метода реализации

(2) принципа организации программного продукта

(3) вендора предоставляющего «коробочный» продукт

(4) участников проектной команды

Применение шаблона позволяет

(1) Избежать организации процессов работы над требованиями

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

(3) Выполнять разработку ПО в максимально короткие сроки

(4) Не работать над нефункциональными требованиями

Стандарт на работу с требованиями должен

(1) Содержать свод правил, которые необходимо неукоснительно выполнять

(2) Описывать методы, правила и инструменты, применяемые для сбора, разработки и управления требованиями, их возможные форматы и нотации

(3) Быть гибким для применения

(4) Описывать подход к верхнеуровневой структуре сбора и агрегации требований

Модернисткой идеей Захмана, изложенной в его модели, было предложение

(1) Рассматривать информационную систему как изменчивую структуру

(2) Рассматривать информационную систему в целом с разных точек зрения/перспектив

(3) Разработать модели управления и эксплуатации технологической инфраструктуры и программных продуктов

(4) Рассматривать информационную систему поэтапно

Если постулировать режим диктатуры, то архитектор рискует попасть в ловушку профессионального одиночества, основными типичными признаками которой являются:

(1) Отсутствие профессионального саморазвития

(2) Синдром высокомерной замкнутости

(3) Исключение возможности ошибки

(4) Отсутствие обратной связи от сотрудников

15 шаблонов архитектурного проектирования представленных Алистером Коуберном преимущественно описывают

(1) факторы «внешнего» влияния на архитектуры, чем составляющие программной инженерии

(2) факторы «внутреннего» влияния на архитектуры

(3) составляющие программной инженерии

(4) факторы влияния решений на структуру приложений в целом

Не функциональные требования это

(1) Не требования

(2) Вид функциональных требований

(3) Вид требований, который позволяет заложить системный базис информационного продукта, на котором станет возможным «вырастить» оптимальную для конкретных условий архитектуру программного продукта

(4) Требования к аппаратному обеспечению

Стандарты должны определять

(1) Временные правила для переходного периода внедрения архитектуры программного продукта

(2) Требования к техническим характеристикам

(3) Рабочие принципы, которые действуют на всем протяжении жизненного цикла программного продукта

(4) Правила реализации проекта по созданию архитектуры программного продукта

В модели "4+1" категория «Физическое представление» отражены

(1) Инструментами анализа и документирования архитектуры программного продукта и связанных с ним предметных бизнес доменов

(2) Статическую организацию программной системы в среде разработки программного продукта

(3) Детали, связанные с физическим размещением программных компонент системы на аппаратных платформах

(4) Специализированными сценариями использования (use cases)

«Дипломатичность» - характеристика Системного архитектора, которая позволяет:

(1) Оказывать стимулирующее воздействие на всех заинтересованных сторон в процессе проектирования и разработки информационной системы

(2) Достигать компромиссных решений по различным техническим аспектам разрабатываемых программных продуктов

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

Договоренность в соответствии, с которой в дальнейшем будет идти развитие продукта это

(1) методология

(2) соглашение по проекту

(3) проекта

(4) контрактные обязательства перед Вендором

Поведение компонента, как основного объекта архитектуры программного продукта, определяется следующими основными группами требований:

(1) Требования к внутреннему интерфейсу/структуре данных, которые определяют характеристики компонента, его преимущества и недостатки

(2) Требования к безопасности, надежности и производительности

(3) Требованиями к внешнему интерфейсу, через который осуществляется взаимодействие с остальными частями архитектуры

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

Классический подход разработки и фиксации функциональных требований состоит в

(1) Разработке требований с помощью итеративной работы с требованиями стэйкхолдеров, и детализации до уровня понятного разработчикам

(2) Детализации требований до уровня понятного разработчикам

(3) Работе только со стэйкхолдерами

(4) Работе с разработчиками

Стратегическая модель архитектуры «SAM» представляет собой

(1) Статическую организацию программной системы в среде разработки программного продукта

(2) Инструмент анализа и документирования архитектуры программного продукта и связанных с ним предметных бизнес доменов

(3) Детали, связанные с физическим размещением программных компонент системы на аппаратных платформах

(4) Описание аспектов порядка и синхронизации исполнения бизнес-процессов

Укажите обязанности Архитектора на стадии «Анализ информации» процесса разработки информационной системы

(1) Он руководит процессом, являясь гарантом валидности разработанного продукта базовой системной архитектуре

(2) Он должен быть поглощен изучением различных бизнес аспектов и связями между ними, а также окружения, в котором будет осуществляться разработка программного продукта

(3) Он собирает и увязывает между собой абстрактные элементы бизнес домена для того, чтобы его команда смогла создать модель проектируемой системы

(4) Он инициирует и управляет обсуждениями на тему системной интеграции

Для перехода с этапа описания архитектуры бизнес-процессов к формированию целостной ИТ-архитектуры, используют следующие предметные области:

(1) архитектура технологий

(2) архитектура ресурсов

(3) архитектура приложений

(4) архитектура данных

Группами единиц измерения размера программ, являются

(1) Теоретическая

(2) Системная

(3) Техническая

(4) Функциональная

Укажите основные группы нефункциональных требований

(1) Юзабилити

(2) Ограничения

(3) Визуальные

(4) Атрибуты качества

Сфера интересов «Подвижные» в модели SAM должна описывать

(1) Наиболее стабильные элементы бизнеса

(2) То, что на конкретном предприятии находится в процессе постоянных изменений

(3) Наименее стабильные элементы бизнеса

(4) Направление бизнеса, что порождает изменение программных продуктов

Укажите обязанности Архитектора на стадии «Тестирование» процесса разработки информационной системы

(1) Он собирает и увязывает между собой абстрактные элементы бизнес домена для того, чтобы его команда смогла создать модель проектируемой системы

(2) Он контролирует процесс тестирования системы на предмет эффективной интеграции и приемлемости параметров системы для заказчика

(3) Он инициирует и управляет обсуждениями на тему системной интеграции

(4) Он руководит процессом, являясь гарантом валидности разработанного продукта базовой системной архитектуре

Функциональная составляющая, разрабатываемой архитектуры приложений формируется по требованию:

(1) Стэйкхолдеров

(2) Вендоров

(3) Архитектора

(4) Пользователей

В «правильном» процессе проектирования архитектуры для того, чтобы привести достоверную оценку, прогнозирование и обоснование спецификаций необходимы следующие данные:

(1) Размер бюджета

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

(3) Структура и содержание комплекта документов, являвшегося результатом выполнения отдельных работ конкретного проекта; Структура и содержание комплекта документов, являвшегося результатом выполнения отдельных работ конкретного проекта.

(4) Ресурсы, выделенные на стадию проектирования

Трассирование представляет собой

(1) Процесс или атрибут в рамках реализации информационный системы, который обеспечивает связь между его элементами и функциональными процессами

(2) Процесс определенного домена бизнеса

(3) Устаревший вариант верификации

(4) Вид анализа требований

Методики MOF и MSM описывают

(1) Подход к разработке архитектуры программных продуктов и инфраструктуры

(2) Аспекты управления и эксплуатации технологической инфраструктуры и программных продуктов

(3) Модель разработки архитектуры программных продуктов и инфраструктуры

(4) Подход к планированию работ по развертыванию инфраструктуры программных продуктов

Подход, при котором будет оптимально интегрироваться друг с другом различные компоненты программного продукта и различные информационные системы, позволит достичь:

(1) Достижение качественного результата процессов архитектурного проектирования

(2) Построения комплексной единой информационной структуры

(3) Согласованного результата процесса мониторинга по программным продуктам компании

(4) Повышения эффективности деятельности компании

Классическому «водопадному» подходу к проектированию архитектуры программных продуктов информационных систем свойственно

(1) Итеративность работы

(2) Постоянное тестирование

(3) Постоянный анализ рисков

(4) Всеобъемлющая и «одноразовая» фиксация требований

Под валидацией понимается процесс

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

(2) Сбора и согласования требований к системе всеми стэйкхолдерами

(3) Успешно проведенное техническое тестирование

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

Архитектура по модели СAFCR должна решать следующие задачи

(1) Быть ценной для стэйкхолдеров с точки зрения подтверждения их ожиданий

(2) Быть оптимальной и доступной по затратам для реализации, совершенствования и развития;

(3) Быть технически реализуемой

(4) Быть гибкой

Подход к построению системы мониторинга «Снизу вверх» предполагает:

(1) Поэтапное построение комплекса мониторинга на основании конкретных требований по каждому отдельному процессу

(2) Система мониторинга создается один раз и в последствии, новые программные продукты, подключаемые к системе мониторинга, начинают контролироваться по согласованным ранее правилам

(3) Формирование в компании Каталога ИТ-услуг и согласуется с идеологией сервисного подхода в управлении ИТ (ITSM)

(4) Система мониторинга создается в первую очередь для ИТ департамента

Эффективное управление документацией программного продукта в процессах архитектурного проектирования может быть выстроено при условии, если выполнены задачи:

(1) Анализ комплексной эффективности документации в процессах анализа,

(2) Разработки требований и последующего архитектурного проектирования

(3) Полного тестирования функционала

(4) Оценка системного влияния различных типов документов на программный продукт, с учетом ресурсов на их реализацию

Среди рисков реализации архитектуры, основными считаются:

(1) Риск ошибочно принятого архитектурного решения

(2) Риск недостатка средств

(3) Риск нехватки времени

(4) Риск смены разработчика

Достоинствами создания собственной корпоративной методологии являются

(1) Дешевизна сопровождения и развития архитектуры

(2) После адаптации разработанные методики будут отражать именно те детали, которые характерны для конкретной компании

(3) Документация и правила будут уникальны для компании

(4) Простота поддержки методологии

Стратегии совершенствования подразумевает

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

(2) Постоянную смену целей и движения в направлении достижении поставленных результатов до определенной степени их воплощения за период времени, пока цели не будут изменены

(3) Постепенное, итерационное повышение качества существующих процессов по направлению к определенной и «малоизменяемой» цели, которую определили в начале своего бизнес пути

(4) Проведение реинжиниринга всех процессов компании с целью их оптимизации

Проектирование - это

(1) вид активности направленный на создание уникального продукта (услуги), последовательность этапов реализации которого, будет определяться «внешними» факторами, и определять его конечные преимущества и недостатки

(2) видение конечного результата реализации информационной системы

(3) процесс формирования структуры проекта

(4) анализ текущего состояния структуры компании и предложение идей об улучшении бизнес-процессов

Один из постулатов программной инженерии, гласит

(1) Для проработки решения, следует привлекать всю проектную команду

(2) Реализованное однажды должно использоваться многократно

(3) Любое изменение должно быть задокументировано

(4) Архитектура должна быть максимально надежной

Ресурсная база организации – это

(1) Фактическая стоимость организации на рынке

(2) Количество выделенных для деятельности ресурсов их доступность, квалификация (если речь идет о специалистах) и надежность

(3) Размер кредитной задолженности организации

(4) Выгода от успешного внедрения стандарта

Аспекты каждого уровня детализируются

(1) Подуровнями

(2) Функциональными дисциплинами

(3) Понятийными дисциплинами

(4) Определениями

Мартин Фаулер, выделяет следующие архитектурные роли:

(1) Architectus Reloadus

(2) Architectus Oryzus

(3) Architectus Integrator

(4) Architectus Conservative

Программные продукты – это

(1) исполняемые процедуры

(2) реализация требований Спонсоров проекта

(3) взаимосвязанные информационные сущности, выполняющие запросы Пользователей

(4) основной элемент большинства современных высокотехнологичных доменов деятельности

Признаком плохой архитектуры является

(1) Стоимость поддержки

(2) Частые изменения структуры

(3) Высокие требования к документированию

(4) Разрозненность систем и их связей

Перечень стандартов и их содержание, на конкретном предприятии, должно определяться на стадии

(1) Реализации

(2) Планирования

(3) Контроля

(4) Инициализации

GAP-компонент применяется для

(1) Описания архитектурных рисков

(2) Описания существующих расхождений между текущим и желаемым состоянием архитектуры

(3) Описания функциональных требований к архитектуре программных продуктов

(4) Описания актуального состояния архитектуры программных продуктов

Одна из основных задач Системного архитектора состоит в:

(1) управлении командой разработки программного продукта

(2) создании процессов коммуникации между «игроками» его команды настолько тесной, насколько это необходимо для разработки программного продукта с заданным уровнем качества

(3) создании эффективной коммуникации с стэйкхолдерами проекта

(4) Отслеживании всех изменений в процессах разработки архитектуры программного продукта

Шаблоны проектирования (design patterns) представляет собой

(1) руководство по реализации

(2) универсальный свод информации

(3) проектная документация на разработку

(4) ограничения по реализации

Под требованиями к программному обеспечению понимают

(1) Совокупность утверждений относительно элементов, характеристик или качеств программной системы, подлежащей реализации

(2) Видение спонсоров проекта

(3) Свод правил компании

(4) Соответствие текущей информационной структуре предприятия

Стандарт на разработку архитектуры программного продукта содержит

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

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

(3) Требования к составу участников внедрения, поддержки продукта и их компетентности

(4) Требования к этапам и перечню работ

В модели "4+1" категория «Логическое представление» играет роль

(1) Модели проектирования разрабатываемой информационной системы

(2) Модели порядка и синхронизации исполнения бизнес-процессов

(3) Деталей, связанных с физическим размещением программных компонентов системы на аппаратных платформах

(4) Специализированных сценариев использования (use cases)

«Готовность и способность к взаимодействию» - черта Системного архитектора, которая позволяет:

(1) Прогнозировать возможные тренды развития архитектуры и предвидеть связанные с этим проблемы

(2) Воздействовать на членов команды с целью побуждения к действию и разделения принятых решений системным архитектором

(3) Оказывать стимулирующее воздействие на всех заинтересованных сторон в процессе проектирования и разработки информационной системы

(4) Достигать компромиссных решений по различным техническим аспектам разрабатываемых программных продуктов

Алистер Коуберн, в своих работах, выделяет 3 стиля применения шаблонов:

(1) неиспользование шаблонов

(2) статическое использование шаблонов

(3) эволюционное использование шаблонов

(4) аналитическое использование шаблонов

Требования должны быть

(1) Простые в понимании

(2) Соответствующие реальным ожиданиям пользователей

(3) Простые в использовании

(4) Согласованны всеми участниками проекта

Требования к программным продуктам принято делить на 2 типа критичности

(1) Регламентированные

(2) Высокоуровневые

(3) Низкоуровневые

(4) Технические улучшения

В модели "4+1" категория «Представление уровня разработки» описывает

(1) Специализированные сценарии использования (use cases)

(2) Статическую организацию программной системы в среде разработки программного продукта

(3) Ограничения

(4) Требования

«Инициативность» - характеристика Системного архитектора, которая проявляется в:

(1) Способности оказывать стимулирующее воздействие на всех заинтересованных сторон в процессе проектирования и разработки информационной системы

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

(3) Достижении компромиссных решений по различным техническим аспектам разрабатываемых программных продуктов

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

Для описания структуры данных компании, в привязке к существующим и планируемым бизнес процессам, используют:

(1) диаграмму ER

(2) диаграмму BPMN

(3) диаграмму EPC

(4) диаграмму EPC

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

(1) Заручится поддержкой спонсоров проекта

(2) Перебросить дополнительные человеческие ресурсы. Привлечь экспертов предметной области

(3) Проанализировать результаты предыдущих проектов

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

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

(1) Персонал

(2) Данные и информация

(3) Время

(4) Финансы

Сфера интересов «Динамичные» в модели SAM определяет

(1) Наиболее стабильные элементы бизнеса

(2) То, что на конкретном предприятии находится в процессе постоянных изменений

(3) Наименее стабильные элементы бизнеса

(4) Направление бизнеса, что порождает изменение программных продуктов

Укажите обязанности Архитектора на стадии «Поддержка и обслуживание» процесса разработки информационной системы

(4) Он инициирует и управляет обсуждениями на тему системной интеграции

«Карта поддержки процессов информационными системами» - это документ позволяющий

(1) производить анализ возможных улучшений процессов

(2) производить поддержку используя прописанные правила и ограничения

(3) верхнеуровнево представлять и отслеживать весь архитектурный ландшафт организации

(4) оперативно реагировать на нестандартные ситуации

Для верификации и последующего изменения документов, каждое функциональное требование должно быть представлено

(1) Неизменно

(2) Уникально и неизменно

(3) Уникально

(4) Определенным стэйкхолдером

Трассировка должна способствовать установлению связи между:

(1) Результатами

(2) Всеми видами требований;

(3) Необходимой отчетностью

(4) Функциональными и нефункциональными процессами;

В архитектурных документах Microsoft выделены следующие типы руководств и обеспечивающих методик

(1) Выработка общего понимания и соглашение о признанном языке описания архитектуры

(2) Выработка частных подходов управления

(3) Выработка общих подходов управления

(4) Указания на использование концепций на практике в форме конкретных технологий стандартов, регламентов и т.д.

Укажите существующие подходы к построению системы мониторинга

(1) Сверху вниз

(2) Технический подход

(3) Снизу вверх

(4) Комбинированный подход

Объект, как элемент архитектуры программного обеспечения, должен поддерживать следующие связи компонентов

(1) Узловые (комплексные процессы)

(2) Динамические (бизнес процессы)

(3) Статические (элементы структуры)

(4) Интеграционные (элементы взаимодействия)

Use cases подход фиксации функциональных требований состоит в

(1) Постоянном и непрерывном общении с определенной группой стэйкхолдеров

(2) Определенном алгоритме взаимодействия с разработчиками

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

(4) Составлении определенного вида документации

Для построения качественной архитектуры по модели SAM, необходимо классифицировать разрабатываемые сферы интересов по следующей топологии:

(1) Динамичные

(2) Статичные

(3) Подвижные

(4) Изменчивые

Укажите обязанности Архитектора на стадии «Проектирование» процесса разработки информационной системы

(2) Он инициирует и управляет обсуждениями на тему системной интеграции

(3) Он изучает различные бизнес аспекты и связи между ними, а также окружение, в котором будет осуществляться разработка программного продукта

Для заказчика программного продукта и групп заинтересованных пользователей имеют значимость следующие результаты процессов разработки и использования конкретного приложения:

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

(2) Финансовая прибыль от разработки ПО

(3) Функциональная эффективность системы; Конкурентоспособность по отношению к другим, аналогичным по функциям, программным продуктам, с учетом его общего качества и стоимости.

(4) Коммуникационная удовлетворенность

Верификация – это

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

(2) Тоже самое что и валидация

(3) Процесс, направленный на доказательство того, что требования стэйкхолдеров не вступают в конфронтацию с принятым стандартом

(4) Процесс, направленный на доказательство того, что требования стэйкхолдеров будут полностью удовлетворены, в разработанной функциональности программного обеспечения

Для проектирования и последующей реализации архитектуры программного продукта конкретной организации следует

(1) Компилировать «собственную» методику создания архитектуры

(2) Применять доступные эталонные образцы общепринятых моделей и методик

(3) Использовать только одну из общепризнанных методик разработки архитектуры

(4) Применять только методики компании Microsoft

Подход к построению системы мониторинга «Комбинированный подход» предполагает:

(2) Система мониторинга создается в первую очередь для ИТ департамента

(3) Система мониторинга создается один раз и в последствии, новые программные продукты, подключаемые к системе мониторинга, начинают контролироваться по согласованным ранее правилам

(4) Формирование в компании Каталога ИТ-услуг и согласуется с идеологией сервисного подхода в управлении ИТ (ITSM)

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

(1) Классификацию и тип документа

(2) Коэффициент значимости или приоритет

(3) Атрибуты учета

(4) Версионность

Для того, чтобы максимально обезопасить программный продукт от риска смены разработчика следует

(1) Поручать разработку команде разработчиков

(2) Все важные решения, стремиться задокументировать в виде концептуально проработанного предложения

(3) Разбить этапы реализации продукта на под-этапы, для контроля степени исполнения

(4) Создать хорошие рабочие условия труда

Критичным требованием к достижению результата разработки оптимального программного продукта является требование

(1) Наличие высококвалифицированной команды разработки

(2) Точного соблюдения рамок внедрения и последующего функционирования системы

(3) Соблюдение выделенного бюджета

Стратегия развития подразумевает

(1) Проведение реинжиниринга всех процессов компании с целью их оптимизации

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

(4) Постепенное, итерационное повышение качества существующих процессов по направлению к определенной и «малоизменяемой» цели, которую определили в начале своего бизнес пути

Архитектурное проектирование - это

(1) процесс реализации пожеланий Стэйкхолдеров

(2) работы по подготовке структуры взаимодействия систем в организации

(3) вид активности, который своей целью ставит создание архитектуры в процессе выполнения проекта

(4) вид работ по определению границ проекта

К нефункциональным характеристикам архитектуры программного обеспечения относят

(1) Безопасность

(2) Надежность

(3) Бизнес-требования

(4) Масштабируемость

Сегмент/домен/направление деятельности компании – это

(1) Сфера деятельности, с учетом специфических требований к ним со стороны отраслевых/государственных/международных регуляторных органов

(2) Позиционирование организации среди других компаний

(3) Вид программного продукта

(4) Компонент организационной структуры компании

Функциональные дисциплины - это

(1) Самодостаточные активности, которые реализуют и поддерживают архитектуру и функциональность программных продуктов

(2) Наиболее стабильные элементы бизнеса

(3) Наименее стабильные элементы бизнеса

(4) Описание архитектуры программных продуктов и инфраструктуры

Архитектурная роль "Architectus Reloadus" описывается Мартином Фаулером как:

(1) сотрудник-руководитель, принимающий большинство важных решений в процессах жизненного цикла программного продукта и поддерживающий концептуальную целостность системы

(2) Architectus Integrator

(3) Architectus Oryzus

(4) человек, осведомлённый обо всём, что происходит в проекте, следящий за всеми трудностями, помогающий предвидеть и объяснять технические последствия нетехнических идей и требований;

Причиной развития темы архитектуры программного обеспечения является

(1) рост издержек предприятий

(2) развитие технологий

(3) нарастающая конкуренция

(4) требования к качеству информационных продуктов

Цель создания архитектурного программного продукта

(1) Провести модернизацию существующих компонентов

(2) Добиться надежности и бесперебойности работы продукта

(3) Увеличить инвестиционную привлекательность компании

(4) Удовлетворение комплекса разноречивых потребностей группы наиболее важных заинтересованных лиц

Стандартизация призвана обеспечить …. повышение качества процессов

(1) Временное

(2) Быстрое

(3) Массовое

(4) Постепенное

Модель Захмана предлагает решение двух основных архитектурных задач

(1) Разработать методики тиражирования архитектурных решений

(2) Выделить самодостаточные активности, которые смогут поддерживать структуру и функциональность программных продуктов

(3) Обеспечить возможность рассмотрения целостной архитектуры с выделенных точек зрения

(4) Логически разбить все описание архитектуры на отдельные разделы для упрощения их формирования и восприятия

«Авторитет» - характеристика Системного архитектора, которая позволяет:

(1) Достигать компромиссных решений по различным техническим аспектам разрабатываемых программных продуктов

(2) Поддерживать свой собственный уровень инициативности на должном качественном уровне

(3) Воздействовать на членов команды с целью побуждения к действию и разделения принятых решений системным архитектором

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

Архитектурные решения - это

(1) соглашения, учитывающие и удовлетворяющие различные точки зрения, «силы», принципы, как технического, так и не технического характера

(2) соглашения, между Архитектором и Командой по реализации

(3) тип используемых методик проектирования

(4) видение конечного результата реализации

Функциональные требования это

(1) Характеристики программного продукта и требования к процессу взаимодействия между информационной системой и пользователями, в котором достигаются бизнес цели и задачи

(2) Безопасность

(3) Надежность

(4) Масштабируемость

Стандарт процесса кодирования

(1) Устанавливает правила учета версионности разработанных компонентов системы

(2) Является вспомогательным средством повышения операционной эффективности

(3) Стратегически важный элемент развития информационных технологий

(4) Регламентирует исходный код программы, его синтаксис, и правила, касающиеся разработки кода программы

В модели "4+1" категория «Процессное представление» применяется для

(1) Описания аспектов порядка и синхронизации исполнения бизнес-процессов

(2) Описания деталей, связанных с физическим размещением программных компонентов системы на аппаратных платформах

(3) Представления программной системы в среде разработки программного продукта

(4) Представления инструментов работы

«Определение наиболее эффективного и адаптируемого рабочего процесса» - способность Системного архитектора, которая позволяет:

(4) Прогнозировать возможные тренды развития архитектуры и предвидеть связанные с этим проблемы

Выбор стиля использования шаблонов производится на основании

(1) имеющихся ресурсов

(2) конкурентной среды

(3) политики организации

(4) требований

Под компонентом понимается

(1) Вид требований

(2) Кусок «кода»

(3) Часть архитектуры программного продукта

(4) Модуль системы или отдельный программный продукт, назначение которого состоит в обработке и инкапсуляции его содержимого

Функциональные требования описывают

(1) Требования к безопасности, надежности и производительности

(2) Требования к аппаратному обеспечению

(3) Возможность модернизации системы

(4) «Поведение» системы и информацию, с которой система будет работать

Связующим артефактом разрабатываемой архитектуры программного продукта, в модели «4+1», являются

(1) Требования

(2) Ограничения

(3) Стандарт качества организации

(4) Специализированные сценарии использования (use cases)

«Абстрактность мышления» характеристика Системного архитектора, которая позволяет:

Часть недопониманий, между различными подразделениями, в большинстве случаев, «снимается» за счет использования

(1) поддержки Руководителей подразделений

(2) группы/семейства нотаций способных поддерживать преобразования диаграмм и моделей

(3) распоряжений

(4) включения в процесс разработки продукта, затрагивающего всех заинтересованных сторон

Факторы «контекста» это

(1) Миссия бизнеса, которую будет поддерживать архитектура программного продукта

(2) Условия, при которых происходит проработка концепта архитектурного решения

(3) Требования, участников проекта

(4) Цель модернизации существующего информационного комплекса

Нефункциональные требования, в дополнение к функциональным, направленны на

(1) Обеспечение технической целостности разрабатываемого функционала и поддержку характеристик реализуемого программного обеспечения

(2) Формирование плана последующей модернизации функционала

(3) Реализацию всех не учтенных функциональных требований

(4) Формирование общего концепта функционала

Сфера интересов «Статичные» в модели SAM должна описывать

(1) Наиболее стабильные элементы бизнеса

(2) Наименее стабильные элементы бизнеса

(3) Направление бизнеса, что порождает изменение программных продуктов

(4) То, что на конкретном предприятии находится в процессе постоянных изменений

Укажите обязанности Архитектора на стадии «Реализация проекта» процесса разработки информационной системы

(2) Он собирает и увязывает между собой абстрактные элементы бизнес домена для того, чтобы его команда смогла создать модель проектируемой системы

(3) Он инициирует и управляет обсуждениями на тему системной интеграции

(4) Он контролирует процесс тестирования системы на предмет эффективной интеграции и приемлемости параметров системы для заказчика

Стадией перехода от архитектуры бизнес-процессов и данных к созданию архитектуры приложений является:

(1) опрос Заинтересованных сторон с целью получения функциональных требований

(2) планирование работ по проектированию

(3) получение готовой полной схемы процессов

(4) определение зависимости между верхнеуровневой архитектурой бизнес-процессов и приложениями

Первый этап работ в жизненном цикле программного продукта это

(1) Разработка ПО

(2) Тестирование

(3) Формирование концепции и набора первичных, высокоуровневых требований к функциональности

(4) Анализ требований

Один из основных постулатов создания качественного и адекватного программного продукта, называется:

(1) Интегрирование

(2) Валидация

(3) Трассирование

(4) Верификация

Методики MSF и MSA применяются для

(1) Описания архитектуры программных продуктов и инфраструктуры

(2) Определения требований к управлению и эксплуатации технологической инфраструктуры и программных продуктов

(3) Разработки архитектуры программных продуктов и инфраструктуры

(4) Планирования работ по развертыванию инфраструктуры программных продуктов

Комплексные системы мониторинга способствуют решению следующих задач:

(1) Влияние сбоя в общем информационном пространстве на смежные продукты и сервисы

(2) Оперативная фиксация проблем в функционировании программных продуктов и «Место», причину сбоя

(3) Экономия ресурсов организации

(4) Проактивное отслеживание изменений в работе и предотвращение потенциальных сбоев

После этапа создания архитектуры приложений наступает этап

(1) поддержки

(2) реализации архитектуры технологий

(3) тестирования

(4) планирования

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

(1) Обзорное рабочее проектирование

(2) Подробное детальное проектирование

(3) Пост-реализационный анализ требований

(4) Первичное архитектурное проектирование

Оптимально выстроенный процесс трассирования должен ясно и однозначно позволять ответить на вопросы:

(1) что (?)

(2) откуда (?)

(3) зачем (?)

(4) каким образом (?)

Архитектурные шаблоны - это

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

(2) Общие руководства по применению узконаправленных концепций

(3) Тип документа, содержащий лучшие практики проектирования информационных систем и средства по минимизации возникающих рисков

(4) Свод требований к управлению и эксплуатации технологических процессов инфраструктуры и программных продуктов

Подход к построению системы мониторинга «Сверху вниз» предполагает что:

(1) Поэтапное построение комплекса мониторинга на основании конкретных требований по каждому отдельному процессу будет соо

(2) Формирование в компании Каталога ИТ-услуг и согласуется с идеологией сервисного подхода в управлении ИТ (ITSM)

(4) Система мониторинга создается в первую очередь для ИТ департамента

Причины разработки документации с неудовлетворительным качеством:

(1) Перекос по выделенным ресурсам в сторону менее значимых документов, не представляющим высокой ценности для последующих процессов

(2) Несбалансированные значения требований к отдельным, взаимосвязанным характеристикам и документам

(3) Передача обязанности подготовки документов неквалифицированным сотрудникам

(4) Отсутствие единого формата подготовки документации

При выполнении тестирования должны быть решены основная задача:

(1) Выявление ситуаций и аспектов, в которых функциональность и архитектура является несоответствующим зафиксированных в документах требованиям с последующим выполнением

(2) Демонстрация соответствия требований реализации программного продукта;

(3) Определение необходимости в дополнительных улучшениях продукта

(4) Проведение поиска возможности снизеть затраты на поддержку продукта

Достоинствами создания собственной корпоративной методологии являются:

(1) Концепции, структуры описания архитектуры и прочие значимые шаблоны будут разработаны с учетом конкретных факторов и условий, определяющих программный продукт и его архитектуру

(3) Документация и правила будут уникальны для компании

(4) Простота поддержки методологии

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

(1) Ограниченности ресурсов по сопровождению системы

(2) Удобства ее дальнейшего сопровождения

(3) Простоты интеграции с другими системами

(4) Возможности повторного использования уже реализованных компонентов

Для пользователей и заинтересованных сторон, ответственных за будущую поддержку и развитие программного продукта наибольшее значение имеют те документы, которые

(1) Регламентировать подход к последующей модернизации

(2) Будут описывать системные ограничения и требования

(3) Будут описывать эффективное применение компонентов и архитектуры программного продукта

(4) Устанавливают требования к квалификации сотрудников, использующих продукт

Архитектура программного продукта состоит из

(1) Функциональных систем

(2) Интеграционных компонентов

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

(4) Самодостаточных активностей, которые поддерживают структуру и функциональность программных продуктов

Сформулированный и продемонстрированный Мартином Фаулером принцип «YAGNI» описывает:

(1) Постепенное, итерационное повышение качества существующих процессов по направлению к определенной и «малоизменяемой» цели, которую определили в начале своего бизнес пути

(4) Проведение реинжиниринга всех процессов компании с целью их оптимизации