Главная / Менеджмент /
Архитектурное проектирование программного обеспечения / Тест 3
Архитектурное проектирование программного обеспечения - тест 3
Упражнение 1:
Номер 1
Перед тем как внедрять стандарты в процессы конкретной организации следует
Ответ:
 (1) Достичь определенного уровня зрелости процессов компании 
 (2) Отказаться от других стандартов 
 (3) Адаптировать их под реалии конкретной организации 
 (4) Оценить возможность обеспечения поддержки стандартов 
Номер 2
Ресурсная база организации – это
Ответ:
 (1) Фактическая стоимость организации на рынке 
 (2) Количество выделенных для деятельности ресурсов их доступность, квалификация (если речь идет о специалистах) и надежность 
 (3) Размер кредитной задолженности организации 
 (4) Выгода от успешного внедрения стандарта 
Номер 3
Сегмент/домен/направление деятельности компании – это
Ответ:
 (1) Сфера деятельности, с учетом специфических требований к ним со стороны отраслевых/государственных/международных регуляторных органов 
 (2) Позиционирование организации среди других компаний 
 (3) Вид программного продукта 
 (4) Компонент организационной структуры компании 
Упражнение 2:
Номер 1
Степень влияние информационных технологий на поддержку и развитие бизнеса определяет
Ответ:
 (1) Инновационность компании и степень участия в инновациях информационных технологий 
 (2) Потенциальный размер прибыли компании 
 (3) Состав и квалификацию руководства компании 
 (4) Управленческие процессы компании 
Номер 2
Перечень стандартов и их содержание, на конкретном предприятии, должно определяться на стадии
Ответ:
 (1) Реализации 
 (2) Планирования 
 (3) Контроля 
 (4) Инициализации 
Номер 3
Стандартизация призвана обеспечить …. повышение качества процессов
Ответ:
 (1) Временное 
 (2) Быстрое 
 (3) Массовое 
 (4) Постепенное 
Упражнение 3:
Номер 1
Стандарт на работу с требованиями должен
Ответ:
 (1) Содержать свод правил, которые необходимо неукоснительно выполнять 
 (2) Описывать методы, правила и инструменты, применяемые для сбора, разработки и управления требованиями, их возможные форматы и нотации 
 (3) Быть гибким для применения  
 (4) Описывать подход к верхнеуровневой структуре сбора и агрегации требований 
Номер 2
Стандарт на разработку архитектуры программного продукта содержит
Ответ:
 (1) Правила, формирующие архитектуру программного продукта, приемлемые и неприемлемые методы её разработки, описывает возможные функциональные и не функциональные ограничения 
 (2) Правила, которые жестко регламентируют роли и ответственность участников проектной команды, с целью фиксирования полученных результатов и контроля исполнения задач 
 (3) Требования к составу участников внедрения, поддержки продукта и их компетентности 
 (4) Требования к этапам и перечню работ 
Номер 3
Стандарт процесса кодирования
Ответ:
 (1) Устанавливает правила учета версионности разработанных компонентов системы 
 (2) Является вспомогательным средством повышения операционной эффективности  
 (3) Стратегически важный элемент развития информационных технологий 
 (4) Регламентирует исходный код программы, его синтаксис, и правила, касающиеся разработки кода программы 
Упражнение 4:
Номер 1
Стандарты должны определять
Ответ:
 (1) Временные правила для переходного периода внедрения архитектуры программного продукта 
 (2) Требования к техническим характеристикам  
 (3) Рабочие принципы, которые действуют на всем протяжении жизненного цикла программного продукта 
 (4) Правила реализации проекта по созданию архитектуры программного продукта 
Номер 2
Требования к программным продуктам принято делить на 2 типа критичности
Ответ:
 (1) Регламентированные 
 (2) Высокоуровневые 
 (3) Низкоуровневые 
 (4) Технические улучшения 
Номер 3
Функциональные требования описывают
Ответ:
 (1) Требования к безопасности, надежности и производительности 
 (2) Требования к аппаратному обеспечению 
 (3) Возможность модернизации системы 
 (4) «Поведение» системы и информацию, с которой система будет работать 
Упражнение 5:
Номер 1
Классический подход разработки и фиксации функциональных требований состоит в
Ответ:
 (1) Разработке требований с помощью итеративной работы с требованиями стэйкхолдеров, и детализации до уровня понятного разработчикам 
 (2) Детализации требований до уровня понятного разработчикам 
 (3) Работе только со стэйкхолдерами 
 (4) Работе с разработчиками 
Номер 2
Use cases подход фиксации функциональных требований состоит в
Ответ:
 (1) Постоянном и непрерывном общении с определенной группой стэйкхолдеров 
 (2) Определенном алгоритме взаимодействия с разработчиками 
 (3) Записи функциональных требований с помощью системы специализированных правил, которые должны фиксироваться определенным образом 
 (4) Составлении определенного вида документации 
Номер 3
Нефункциональные требования, в дополнение к функциональным, направленны на
Ответ:
 (1) Обеспечение технической целостности разрабатываемого функционала и поддержку характеристик реализуемого программного обеспечения 
 (2) Формирование плана последующей модернизации функционала 
 (3) Реализацию всех не учтенных функциональных требований 
 (4) Формирование общего концепта функционала 
Упражнение 6:
Номер 1
Укажите основные группы нефункциональных требований
Ответ:
 (1) Юзабилити  
 (2) Ограничения 
 (3) Визуальные 
 (4) Атрибуты качества 
Номер 2
Запланированное функционирование бизнес процессов, необходимо обеспечить следующими требованиями к ресурсам, которые могут быть кратко выражены следующими аспектами
Ответ:
 (1) Персонал 
 (2) Данные и информация 
 (3) Время 
 (4) Финансы 
Номер 3
Один из основных постулатов создания качественного и адекватного программного продукта, называется:
Ответ:
 (1) Интегрирование 
 (2) Валидация 
 (3) Трассирование 
 (4) Верификация 
Упражнение 7:
Номер 1
Трассирование представляет собой
Ответ:
 (1) Процесс или атрибут в рамках реализации информационный системы, который обеспечивает связь между его элементами и функциональными процессами 
 (2) Процесс определенного домена бизнеса 
 (3) Устаревший вариант верификации 
 (4) Вид анализа требований 
Номер 2
Трассировка должна способствовать установлению связи между:
Ответ:
 (1) Результатами 
 (2) Всеми видами требований; 
 (3) Необходимой отчетностью 
 (4) Функциональными и нефункциональными процессами; 
Номер 3
Оптимально выстроенный процесс трассирования должен ясно и однозначно позволять ответить на вопросы:
Ответ:
 (1) что (?) 
 (2) откуда (?) 
 (3) зачем (?) 
 (4) каким образом (?) 
Упражнение 8:
Номер 1
Под валидацией понимается процесс
Ответ:
 (1) Направленный на доказательство того, что требования стэйкхолдеров не вступают в конфронтацию с принятым стандартом 
 (2) Сбора и согласования требований к системе всеми стэйкхолдерами 
 (3) Успешно проведенное техническое тестирование 
 (4) Направленный на доказательство того, что требования стэйкхолдеров будут полностью удовлетворены, в разработанной функциональности программного обеспечения 
Номер 2
Верификация – это
Ответ:
 (1) Активность процесса валидации, цель которой проверка и последующее достижение соответствия между требованием и реализованными архитектурой и функциональность программного обеспечения 
 (2) Тоже самое что и валидация 
 (3) Процесс, направленный на доказательство того, что требования стэйкхолдеров не вступают в конфронтацию с принятым стандартом 
 (4) Процесс, направленный на доказательство того, что требования стэйкхолдеров будут полностью удовлетворены, в разработанной функциональности программного обеспечения 
Номер 3
При выполнении тестирования должны быть решены основная задача:
Ответ:
 (1) Выявление ситуаций и аспектов, в которых функциональность и архитектура является несоответствующим зафиксированных в документах требованиям с последующим выполнением 
 (2) Демонстрация соответствия требований реализации программного продукта; 
 (3) Определение необходимости в дополнительных улучшениях продукта 
 (4) Проведение поиска возможности снизеть затраты на поддержку продукта 
Упражнение 9:
Номер 1
Среди рисков реализации архитектуры, основными считаются:
Ответ:
 (1) Риск ошибочно принятого архитектурного решения 
 (2) Риск недостатка средств 
 (3) Риск нехватки времени 
 (4) Риск смены разработчика 
Номер 2
Для того, чтобы максимально обезопасить программный продукт от риска смены разработчика следует
Ответ:
 (1) Поручать разработку команде разработчиков 
 (2) Все важные решения, стремиться задокументировать в виде концептуально проработанного предложения 
 (3) Разбить этапы реализации продукта на под-этапы, для контроля степени исполнения  
 (4) Создать хорошие рабочие условия труда