Отношение между сценариями использует означает что

Упражнение 1:

Номер 1

Разработка требований включает в себя следующие основные разделы:

Ответ:

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

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

(3) управление требованиями 

(4) систематизация требований 

Номер 2

Раздел "Анализ требований" разработки требований включает в себя следующие подразделы:

Ответ:

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

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

(3) техника обсуждения 

(4) валидация требований 

Номер 3

Определение требований, как правило, проводится:

Ответ:

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

(2) путем обсуждения системы между будущими ее разработчиками без участия заказчика 

(3) путем сбора требований к системе заказчика без участия будущих ее разработчиков 

Упражнение 2:

Номер 1

Разработка требований не включает в себя следующие основные разделы:

Ответ:

(1) управление требованиями 

(2) инженерия требований 

(3) проверка требований 

Номер 2

Инженерия требований включает в себя следующие подразделы:

Ответ:

(1) улучшение качества 

(2) систематизация требований 

(3) модель процессов ЖЦ 

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

Номер 3

Управление требованиями не включает в себя следующие подразделы:

Ответ:

(1) извлечение требований 

(2) оценка качества 

(3) связь с процессами 

(4) спецификация требований 

Упражнение 3:

Номер 1

Требования к ПО состоят из:

Ответ:

(1) системных требований 

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

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

(4) несистемных требований 

Номер 2

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

Ответ:

(1) конфиденциальность, безопасность и защита данных 

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

(3) стоимость системы 

(4) отказоустойчивость 

(5) производительность 

Номер 3

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

Ответ:

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

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

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

Упражнение 4:

Номер 1

Требования пользователей определяют:

Ответ:

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

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

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

Номер 2

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

Ответ:

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

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

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

Номер 3

Системные требования определяют:

Ответ:

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

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

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

Упражнение 5:

Номер 1

С какими целями проводится обсуждение проекта системы?

Ответ:

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

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

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

Номер 2

Методы сбора требований включают в себя:

Ответ:

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

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

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

Номер 3

Результаты обследования и анализа предметной области фиксируются в:

Ответ:

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

(2) документе описания предметной области 

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

Упражнение 6:

Номер 1

В обсуждении требований на систему принимают участие:

Ответ:

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

(2) специалисты, производящие инсталляцию системы 

(3) аналитики и разработчики будущей системы 

Номер 2

Что дает согласованная область действий по проекту?

Ответ:

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

(2) возможность автоматизировать процесс разработки проекта 

(3) возможность оценить требуемые инвестиции в проект 

Номер 3

Анализ требований не включает в себя подразделы:

Ответ:

(1) описание документа 

(2) согласование документа 

(3) техника обсуждения 

Упражнение 7:

Номер 1

Управление требованиями к системе - это:

Ответ:

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

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

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

Номер 2

Основные задачи управления требованиями - это:

Ответ:

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

(2) управление рисками, возникающими при неточном определении требований 

(3) валидация требований 

(4) реализация требований на этапах ЖЦ 

(5) контроль статуса требований 

Номер 3

Управление рисками, возникающими при неточном определении требований, состоит:

Ответ:

(1) в оценке их влияния на другие процессы 

(2) в предупреждении рисковых ситуаций 

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

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

Упражнение 8:

Номер 1

Фиксация требований включает в себя подразделы:

Ответ:

(1) спецификация требований 

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

(3) согласование документа 

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

(5) систематизация требований 

Номер 2

Спецификация требований к ПО - это:

Ответ:

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

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

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

Номер 3

Фиксация требований не включает в себя подразделы:

Ответ:

(1) спецификация требований 

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

(3) согласование документа 

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

(5) систематизация требований 

Упражнение 9:

Номер 1

Типы трассируемости требований включают в себя следующие направления:

Ответ:

(1) от потребностей к требованиям 

(2) от потребностей к рабочим продуктам 

(3) от требований к потребностям 

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

Номер 2

Трассирование требований включает в себя подразделы:

Ответ:

(1) просмотр требований 

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

(3) приемка требований 

(4) управление изменениями 

Номер 3

Трассировка обеспечивает:

Ответ:

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

(2) автоматическое формирование требований к системе 

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

Упражнение 10:

Номер 1

Основные средства UML к формированию и представлению требований к системе и к ПО - это:

Ответ:

(1) use case сценарии или прецеденты 

(2) диаграммы активности 

(3) диаграммы классов 

Номер 2

Укажите правильную цепочку трансформаций при сценарном подходе:

Ответ:

(1) проблема — объект — сценарий — цель 

(2) проблема — сценарий — объект — цель 

(3) проблема — цель — сценарий — объект 

Номер 3

Укажите корректные правила для специальной графической нотации в модели сценариев:

Ответ:

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

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

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

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

Упражнение 11:

Номер 1

Отношение между сценариями "расширяет" означает, что:

Ответ:

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

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

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

Номер 2

Отношение между сценариями "использует" означает, что:

Ответ:

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

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

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

Номер 3

Описание сценария включает в себя:

Ответ:

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

(2) краткое содержание сценария в неформальном представлении 

(3) описание классов системы 

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

Упражнение 12:

Номер 1

Модель прецедентов моделируемой цели системы состоит из:

Ответ:

(1) основных действующих лиц и их целей 

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

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

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

Номер 2

Модель прецедентов моделируемой цели системы не включает в себя:

Ответ:

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

(2) подробное описание предметной области 

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

(4) используемые термины предметной области 

Номер 3

Экземпляр прецедента - это:

Ответ:

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

(2) неформальное описание каждого из входящих в нее диаграмм сценариев 

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

<Модель прецедента> ::= 
    <имя прецедента/действующего лица>, 
    <имя роли / краткое описание роли действующего лица>,
    <описание границ системы>, 
    <список всех заинтересованных лиц в анализе ключевых целей системы>, 
    <исходные условия>, 
    <результат успешного завершения определения целей системы>, 
    <шаги сценария для формирования шаблона достижения целей проекта>, 
    <описание информации, необходимой разработчику для реализации системы>.

Процесс создания ПИК включает в себя:

Если интерфейс реализуется с помощью класса, то:

Какие модели создаются в процессе моделирования?

Метод проектирования UML предназначен для:

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

Главная цель объектного анализа — это:

Императивные средства КЯ — это:

Операции реверсной инженерии над компонентами удовлетворяют условиям:

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

Управление процессом разработки состоит в:

Спецификация программы — это:

Инструментальные средства — это:

Описание сценария включает в себя:

В обязанности инженера-тестировщика не входят:

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

Область знаний «Управление инженерией ПО» не включает в себя разделы:

Цель тестирования — это:

Диаграмма Ганта — это:

Базис конфигурации — это:

Фильтр композиции служит для:

Ошибки ввода-вывода и манипулирования данными являются следствием:

В таблице перехода в состояния:

Область знаний «Управление инженерией ПО» состоит из следующих разделов:

Атрибут — это:

Жизненный цикл программной системы — это:

Инструменты инженерии ПО обеспечивают:

Репозитарий — это:

Категория «Процессы поддержки» процессов жизненного цикла в стандарте ISO/IEC 12207 не включает в себя:

Внесение изменений в ПО можно рассматривать как:

Реорганизация кода для улучшения характеристик и показателей качества объектно-ориентированных и компонентных программ без изменения их поведения — это:

Организационными областями программной инженерии являются:

Требования — это:

Проектирование ПО — это:

В область знаний «Конструирование ПО» не входят разделы:

Тестирование эффективности ПО позволяет проверить:

Чем считается сопровождение в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764?

Аудит конфигурации ПО — это:

Основными целями процесса являются:

Инструменты инженерии ПО обеспечивают:

К характеристикам качества относят:

Главными областями программной инженерии не являются:

Процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам — это:

Высокоуровневое представление структуры системы и спецификация ее компонентов — это:

В область знаний «Конструирование ПО» не входят разделы:

Тестирование эффективности ПО не позволяет проверить:

Процесс сопровождения согласно стандарту ISO/IEC 14764 проводится путем:

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

Область знаний «Управление инженерией ПО» состоит из следующих разделов:

Область знаний «Процесс программной инженерии» состоит из следующих разделов:

Методы инженерии ПО — это:

Качество ПО — это:

Категория «Организационные процессы» процессов жизненного цикла в стандарте ISO/IEC 12207 включает в себя:

Разработка требований включает в себя следующие основные разделы:

Разработка требований не включает в себя следующие основные разделы:

Требования к ПО состоят из:

Системные требования определяют:

Результаты обследования и анализа предметной области фиксируются в:

В обсуждении требований на систему принимают участие:

Управление рисками, возникающими при неточном определении требований, состоит:

Фиксация требований включает в себя подразделы:

Трассирование требований включает в себя подразделы:

Укажите правильную цепочку трансформаций при сценарном подходе:

Модель прецедентов моделируемой цели системы не включает в себя:

Предметная область — это:

Сущность — это:

Сколько этапов анализа предметной области в методе OOAS Шлеера и Меллора?

Атрибуты бывают:

Последовательность выполняемых процессов образует:

Задачи проектирования — это:

Стандарт ГОСТ 34.601-90, регламентирующий стадии и этапы процесса разработки АС, обеспечивает:

Техническое проектирование — это:

4-й уровень — прикладные программные системы — осуществляют:

Что осуществляет абстрактный объект-посредник?

Сущность структурного подхода к разработке ПС — это:

Объектно-ориентированный подход (ООП) — это:

Диаграмма последовательности задает:

Ассоциация — это:

Компонент, как физическая сущность:

Аспектно-ориентированное программирование (АОП) — это:

Технология разработки прикладной системы с использованием АОП не включает следующие общие этапы:

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

Агент обладает следующими свойствами:

Алгебраическое программирование — это:

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

Алгебра схем Янова — это:

Дерево — это:

Отображение — это:

Метод Флойда основан:

Валидация требований не включает следующие шаги:

Метод простого структурного анализа ориентирован на:

К событиям процесса относятся:

Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:

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

Международный проект по разработке «целостного автоматизированного набора инструментов для проверки корректности ПС» включает следующие основные задачи:

Тестирование включает в себя:

Основные задачи процессов верификации и валидации:

Инспекция ПО — это:

Динамические методы тестирования используются:

В задачи функционального тестирования не входят:

Под инфраструктурой процесса тестирования понимается:

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

Типы отказов не включают в себя:

Тесты проверяют:

План тестирования содержит:

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

Виды интерфейсов не включают в себя:

Интерфейсные операции класса подразделяются на:

В функции интерфейсного посредника клиента не входит:

Удаленный вызов разноязыковых программ предполагает:

Интерфейс между Visual Basic и другими ЯП осуществляется с помощью:

Независимые от ЯП типы данных стандарта ISO/IEC 11404-1996 не включают:

Внутреннее преобразование типов данных обладает следующими свойствами:

XDR-стандарт:

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

По сравнению с более радикальными подходами к совершенствованию систем реинженерия имеет следующие преимущества:

Операции рефакторинга над компонентами удовлетворяют условиям:

Инженерия повторного использования компонентов (ПИК) — это:

Повторные компоненты могут быть:

К компонентам общего назначения не относятся:

ПИК=(T,I,F,R,S), где R — это:

Внешняя часть компонента — это:

Паттерн — это:

В функции интерфейсного модуля клиента входят:

Репозитарий в интегрированной среде ПрО не включает в себя:

Основное требование к инженерии ПрО — это:

Множество компонентов и систем образуют семейство продуктов, если:

Стоимость поиска и исследования возможностей применения ПИК из репозитария для реализации некоторой определенной функции ПрО вычисляется с помощью выражения:

Какими аспектами характеризуется качество ПО?

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

Функциональность — это:

Переносимость — это:

К подхарактеристикам надежности ПО относятся:

Внутренние метрики продукта включают:

Наработка на отказ как атрибут надежности определяет:

Планирование качества представляет собою:

Оценка надежности сложных ПС зависит от:

Интенсивность отказов — это:

Оценочные модели надежности:

Марковская модель:

Какие задачи управления проектом входят на данный момент в диаграммную схему, созданную Генри Гантом для учета времени выполнения проекта?

Ответственность за идейную, функциональную сторону проекта несет:

Структура ведения проекта, описанная Вейнбергом, предполагает:

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

Под конфигурацией системы понимается:

Согласно стандарту IEEE Std.610-90 управление конфигурацией включает следующие задачи:

Управление конфигурацией — это:

Управление версиями состоит в:

Суть учета статуса состоит в:

Компонент — это:

Паттерн:

Компоненты, которые управляются событиями:

BlankAntProject — это:

Exception — это:

ORB class — это:

Skeleton class — это:

Stub-интерфейс — это:

Сервлет — это:

RUP (Rational Unified Process) — это:

Модель процесса разработки ПО — это:

Модель проектной группы — это:

CustomTask — это:

Надежность — это:

Свойства ПИК могут быть:

Виды интерфейсов включают в себя:

Раздел «Анализ требований» разработки требований включает в себя следующие подразделы:

Стоимость композиции компонентов определяется так:

Сборка ПО — это:

Концептор — это:

Динамическое тестирование включает в себя следующие методы:

Главными областями программной инженерии являются:

Компоненты сеансов:

Что дает согласованная область действий по проекту?

Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:

Процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам — это:

Детальное рабочее проектирование — это:

Методы функционального тестирования подразделяются на:

Интероперабельность — это:

В рамках инженерии ПрО используются следующие типы компонентов в терминологии системы CORBA:

Компоненты сущностей:

Контекст — это:

Контейнер:

Отношение между сценариями «расширяет» означает, что:

Каждый тип данных в стандарте имеет шаблон, включающий:

Stub class — это:

Организационными областями программной инженерии являются:

Проектирование ПО — это:

Координация агентов — это:

К факторам гарантии надежности относятся:

Функциональный аудит конфигурации проводится:

Задание поискового образа ПИК на основе информационной его модели обеспечивает:

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

Методы анализа структуры программ проверяют:

Валидация требований — это:

Высокоуровневое представление структуры системы и спецификация ее компонентов — это:

Выберите верные утверждения:

Реорганизация кода для улучшения характеристик и показателей качества объектно-ориентированных и компонентных программ без изменения их поведения — это:

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

К инструментам конструирования ПО относятся:

Качество ПО — это:

Категория «Организационные процессы» процессов жизненного цикла в стандарте ISO/IEC 12207 включает в себя:

Конструирование ПО — это:

Тестирование ПО — это:

К характеристикам качества относят:

Жизненный цикл программной системы — это:

Инженерия требований включает в себя следующие подразделы:

Требования пользователей определяют:

С какими целями проводится обсуждение проекта системы?

Анализ требований не включает в себя подразделы:

Фиксация требований не включает в себя подразделы:

Типы трассируемости требований включают в себя следующие направления:

Модель прецедентов моделируемой цели системы состоит из:

Концепт — это:

Связи между объектами могут быть:

Связи объектов устанавливаются между:

Событие — это:

Таблица перехода в состояния служит для:

Условия построения архитектуры системы включают в себя:

При концептуальном проектировании определяются:

Архитектурная схема может быть:

Процесс разработки в среде ООП не включает в себя следующие этапы:

Атрибутами могут быть следующие типы значений в UML:

Шаблон (паттерн) — это:

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

Алгебра Дейкстры — это:

Категории языков спецификации включают в себя:

Отображение — это:

Декларативные средства КЯ — это:

Метод Дейкстры основан:

Основные систематические методы обеспечения правильности программ — это:

Свойство компонента C включается в абстракцию P только тогда, когда:

Цель процесса валидации:

Статический анализ заключается в:

Объекты тестирования не включают в себя:

В соответствии с международным стандартом ANSI/IEEE-729-83 дефект (fault) — это:

Тест — это:

Программный (API) и/или аппаратный интерфейс (port) — это:

Динамический интерфейс от объекта клиента к объекту сервера и обратно выполняет:

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

Интерфейс между Matlab и другими ЯП осуществляется с помощью:

Проблема преобразования и переноса данных между различными СУБД решается на основе использования:

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

Метод рефакторинга компонента — это:

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

Внутренняя часть компонента включает в себя:

Развертка — это:

ПС, построенная из компонентов и предназначенная для функционирования в распределенной среде, состоит из:

К альтернативным свойствам ПИК относятся:

Качество ПО — это:

Удобство применения — это:

Сопровождаемость — это:

Достижение надежности ПО обеспечивается:

Метрики программного продукта включают:

Количественными называются показатели качества, которые определяются с помощью:

Инженерия качества — это:

Прогнозирующие модели надежности:

Пуассоновская модель:

Управление проектом — это:

Поддержка темпа работы не предполагает:

Контроль конфигурации — это:

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

Важнейшее свойство компонента:

SampleAntProject — это:

Интерфейс сервисов ORB — это:

К объектным адаптерам, позволяющим экземплярам объектов обращаться к сервисным функциям ORB, не относится:

Модель управления рисками — это:

К основным принципам структурного метода относятся:

Тестирование ПО — это:

Отказ ПC — это:

Аудит конфигурации ПО — это:

На современном рынке программных продуктов циркулируют следующие виды готовых компонентов:

Внешнее преобразование типов данных обладает следующими свойствами:

Внутренняя часть компонента — это:

Типы данных в стандарте описываются в:

Разработке ПС с помощью ПИК соответствует модель ЖЦ со следующими общими этапами:

В основе генерации модели ПрО для семейства ПС лежит:

Типы данных подразделяются на:

В задачи функционального тестирования входят:

Независимые от ЯП типы данных стандарта ISO/IEC 11404-1996 делятся на:

Предусловие — это:

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

Интерфейс DII (интерфейс динамического вызова объекта) — это:

XML-стандарт:

Деятельности и техники гарантии качества включают:

Каркас — это:

Interface — это:

К подхарактеристикам надежности ПО не относится:

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

Отношение между сценариями «использует» означает, что:

Отношение — это:

Анализ домена состоит в:

Класс — это:

Implementation class — это:

Определение требований, как правило, проводится:

Требования — это:

Сколько уровней представления имеет модель качества ПО?

Планирование управления рисками — это:

Управление требованиями к системе — это:

Организационная структура проекта подбирается на основании следующих данных:

Более крупные образования компонентов, используемые на практике — это:

Выберите верные утверждения:

Тестирование эффективности ПО позволяет проверить:

Качественный анализ процесса состоит в:

Управление требованиями не включает в себя следующие подразделы:

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

Методы сбора требований включают в себя:

Основные средства UML к формированию и представлению требований к системе и к ПО — это:

Этапами стандарта ГОСТ 34.601-90, регламентирующего стадии и этапы процесса разработки АС, являются:

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

Абстрагирование — это:

Диаграмма деятельности задает:

Диаграмма реализации состоит из:

Технология разработки прикладной системы с использованием АОП включает следующие общие этапы:

Генерирующее программирование — это:

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

История функционирования транзитивной системы хранит одно из соответствующих состояний:

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

Языки спецификации областей включают в себя следующие языки:

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

Метод символьной проверки применяется при:

Схема спецификации процесса — это:

Международный проект по разработке «целостного автоматизированного набора инструментов для проверки корректности ПС» предполагает, что:

Теоретические средства — это:

Цель процесса верификации:

Тесты не проверяют:

Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 включает:

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

К видам сопровождения относятся:

Реинженерия (reengineering) — это:

К общесистемным компонентам относятся:

Репозитарий в интегрированной среде ПрО включает в себя:

Рациональность — это:

Планирование — это:

Ответственность за координацию и реализацию основных составляющих проекта несет:

В ядре РМВОК определены следующие основные аспекты разработки проектов:

Что не входит в понятие главных факторов осуществления задач программного проекта?

Версия или конфигурация системы состоит из:

Физический аудит конфигурации проводится:

Модель производственной архитектуры — это:

Взаимодействие объектов — это:

Поисковый образ упрощает поиск и сокращает сроки разработки ПС за счет:

В обязанности инженера-тестировщика входят:

Главный показатель качества ПО — это:

Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 не включает:

Метрики использования позволяют оценить:

Объект предметной области — это:

Модель процесса проектирования — это:

Persistence-Capable — это:

Маршалинг данных — это:

К событиям процесса не относятся:

Чем считается сопровождение в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764?

Основными целями процесса являются:

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

Основные задачи управления требованиями — это:

Спецификация требований к ПО — это:

Укажите корректные правила для специальной графической нотации в модели сценариев:

В методе OOAS Шлеера и Меллора предусмотрены следующие нотации для представления динамических аспектов поведения объектов:

Валидация требований — это:

Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:

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

В соответствии с международным стандартом ANSI/IEEE-729-83 ошибка (error) — это:

ПИК=(T,I,F,R,S), где I — это:

ПС, построенная из компонентов и предназначенная для функционирования в распределенной среде, состоит из:

Требования, предъявляемые к качеству ПО, ставятся в соответствии с:

Дефект в ПС — это:

Измерительные модели надежности:

Модель Шика-Вулвертона:

Основными составляющими любого проекта являются:

Риски могут быть:

Каркас

Client class — это:

Модель анализа — это:

К инструментам конструирования ПО относятся:

Чем отличается метод анализа и оценки PERT от метода критического пути CPM?

Функциональные тесты создаются по:

Информационная модель — это:

UML — это:

Компоненты любого из уровней архитектуры системы используются, как правило:

Валидация требований — это:

Главными областями программной инженерии являются:

Процесс разработки в среде ООП включает в себя следующие этапы:

Активные библиотеки содержат:

Транзитивные системы называют бисимуляционно эквивалентными, если:

Объединение — это:

Валидация требований включает следующие шаги:

Отладка — это:

В соответствии с международным стандартом ANSI/IEEE-729-83 отказ (failure) — это:

Типичные причины внесения изменений это:

ПИК=(T,I,F,R,S), где T — это:

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

Стоимость анализа функций ПрО имеет вид:

Сетевая разбивка работ (СРР) — это:

Результатом управления конфигурацией является:

После получения новой версии системы заказчику передаются:

1-й уровень — системные компоненты — осуществляют:

Согласно методу OOAS Шлеера и Меллора, анализ предметной области производится следующими этапами:

Модель состояний отображает:

Модель процессов отражает:

Метод Маккарти основан:

Модель ОКМ — это:

Интерфейс между Perl и другими ЯП осуществляется с помощью:

Оценка качества ПО согласно четырехуровневой модели качества начинается с:

При подходе, ориентированном на продукт, оценка качества проводится после испытания ПС. Этот подход базируется на предположении, что:

ПС следует относить к классу:

Количественная оценка рисков — это:

Server class — это:

Модель приложения — это:

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

Принципами ЭП не являются:

Интерфейс в ООП — это:

Реализация — это:

Идентификация конфигурации — это:

Функции репозитария не включают в себя:

Сборка ПО — это:

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

Трассировка обеспечивает:

Объекты алгоритмики — это:

Экземпляр прецедента — это:

Архитектура системы — это:

Анализ проекта состоит в:

которые объекты посылают друг другу;

– модель процессов определяет действия, которые выполняют объекты.

Все объектные методы имеют в своем составе приведенные модели, отличающиеся своими нотациями и некоторыми другими деталями.

3.2.1. Метод инженерии требований А. Джекобсона

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

Автор назвал свой метод как базирующийся на вариантах (примерах или сценариях – use case driven) системы, которую требуется построить. В дальнейшем термин сценарий используется для обозначения варианта представления системы.

Сложность проблемы обычно преодолевается путем декомпозиции ее на отдельные компоненты с меньшей сложностью. Большая система может быть сложной, чтобы представить ее компоненты программными модулями. Поэтому разработка системы с помощью данного метода начинается с осмысления того, для кого и для чего создается система.

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

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

Следующим шагом после выявления целей является определение носителей интересов,

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

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

71

снижения сложности ее частей и повышения уровня формализации моделей ее представления.

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

Каждый сценарий инициируется определенным пользователем, являющимся носителем интересов. Абстракция определенной роли личности пользователя– инициатора запуска определенной работы в системе, представленной сценарием, и обмена информацией с системой — называется актером. Это абстрактное понятие обобщает понятие действующего лица системы. Фиксация актеров можно рассматривать, как определенный шаг выявления целей системы через роли, которые являются носителями целей и постановщиками задач, для решения которых создается система.

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

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

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

Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса, в роли которого выступает описание транзакции.

Сценарий определяет протекание событий в системе и обладает состоянием и поведением. Каждое взаимодействие между актером и системой это новый сценарий или объект. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев. Вызов сценария – это порождение экземпляра класса. Таким образом, сценарии – это транзакции с внутренним состоянием.

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

72

Можно выделить базовую цель событий, существенную для сценария, а также альтернативные, при ошибках пользователя и др.

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

–актер обозначается иконой человека, под которой указывается название;

–сценарий изображается овалом, в середине которого указывается название иконы;

– актер связывается стрелкой с каждым запускаемым им сценарием.

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

Занесение денег на счет

Снятие денег со счета

Передача денег со счета на счет

Рис.3.2. Пример диаграммы сценариев для клиента банка

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

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

Для сценариев определены два типа отношений:

Отношение «расширяет» означает, что функции одного сценария является дополнением к функциям другого, и используется когда имеется несколько вариантов одного и того же сценария. Инвариантная его часть изображается как основной сценарий, а отдельные варианты как расширения. При этом основной сценарий является устойчивым, не меняется при расширении вариантов функций и не зависит от них.

Типовой пример отношения расширения: моделирование необязательных фрагментов сценариев приведен на рис.3.3. При выполнении сценария расширение прерывает

73

выполнение основного расширяемого сценария, причем последний не знает, будет ли расширение и какое. После завершения выполнения сценария расширение будет продолжено путем выполнения основного сценария.

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

Оба отношения – инструменты определения наследования, если сценарии считать объектами. Отличие между ними состоит в том, что при расширении функция рассматривается как дополнение к основной функции и может быть понятной только в паре с ней, тогда как в отношении «использует » дополнительная функция имеет самостоятельное определение и может быть использована всюду.

Безусловное выполнение предложени

Рис.3.3. Примеры расширения сценариев

На рис. 3.4. показано, что сценарий «сортировать» связан отношением «использует» с несколькими сценариями.

74

Рис.3.4. Пример отношения «использует «

Таким образом, продуктом первой стадии инженерии требований (сбора требований) является модель требований, которая состоит с трех частей:

1)онтология домена;

2)модель сценариев, называемая диаграммой сценариев;

3)описание интерфейсов сценариев.

Модель сценариев сопровождается неформальным описанием каждого из сценариев. Нотация такого описания не регламентируется. Как один из вариантов, описание сценария может быть представлено последовательностью элементов:

–название, которое помечает сценарий на диаграммах модели требований и служит средством ссылки на сценарий;

–аннотация (краткое содержание в неформальном представлении);

–актеры, которые могут запускать сценарий;

–определение всех аспектов взаимодействия системы с актерами (возможные действия актера и их возможные последствия), а также запрещенных действий актера;

–предусловия, которые определяют начальное состояние на момент запуска сценария, необходимое для успешного выполнения;

–функции, которые реализуются при выполнении сценария и определяют порядок, содержание и альтернативу действий, выполняемых в сценарии;

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

–реакции на предвиденные нестандартные ситуации;

–условия завершения сценария;

–постусловия, которые определяют конечное состояние сценария при его завершении.

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

–механизмы запуска сценария (позиции меню);

–механизмы ввода данных;

–поведение при возникновении чрезвычайных ситуаций.

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

75

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

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

3.2.2. Модель анализа требований. Определение объектов

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

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

–изменение требований неизбежно;

–объект модифицируется вследствие изменения соответствующих требований к системе;

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

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

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

–определение поведения системы;

–презентация системы (ее интерфейсов с пользователями и другими системами).

Выбор критериев обусловлен экспертными исследованиями динамики изменений действующих систем.

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

Рассматривается три типа объектов:

–объекты-сущности;

–объекты интерфейса;

–управляющие объекты.

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

76

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

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

Управляющие объекты — это объекты, которые превращают информацию, введенную объектами интерфейса и представленную объектами-сущностями, в информацию, что выводится интерфейсными объектами. Они являются своеобразным «клеем» для соединения объектов, связывая цепочки событий и задавая взаимодействие объектов.

Такое распределение служит целям локализации изменений в системе. При преобразовании модели требований в модель анализа каждый сценарий разбивается на эти три типа объектов. При этом один и тот же объект может присутствовать в нескольких сценариях, и важно распознать такие объекты, чтобы унифицировать их функции и определить их как единый объект. Критерий распознавания состоит в том, что если в различных сценариях имеется ссылка на один и тот же экземпляр объекта, то это один и том же объект.

Атрибуты объектов представлены прямоугольниками, объединенными прямой линией с символом объекта, при этом на линии указывается название атрибута, а в прямоугольнике – его тип.

Между объектами определяются ассоциации, которые изображаются одной– или двунаправленной стрелкою, на которых указываются названия ассоциаций типа:

–взаимодействует,

–составляется с,

–выполняет роль,

–наследует,

–расширяет,

–использует.

Эти ассоциации существенно отличаются от ассоциаций в моделях данных. Последние нацелены преимущественно на осуществление навигации в БД, тогда как ассоциации определяют взаимодействие объектов.

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

– онтология домена;

77

–модель сценариев;

–неформальное описание сценариев и актеров;

–описание интерфейсов сценариев и актеров;

–диаграммы взаимодействия объектов сценариев.

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

3.3. Классификация требований

Формируемые требования к системе разделены на две категории:

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

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

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

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

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

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

–конфиденциальность;

–отказоустойчивость;

–одновременность доступа к системе пользователей;

–безопасность;

–время ожидания ответа на обращение к системе;

78

–ограничения на исполнительские функции системы ( ресурсы памяти, скорость реакции на обращение к системе и т.п.);

–регламентации действующих стандартов, упрощающих процессов организации формирования требований и менеджмента.

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

Определяются объекты и субъекты защиты. На этапе анализа системы решается вопрос, какой уровень защиты данных необходимо предоставить для каждого из компонентов системы, выделить критичные данные, доступ к которым строго ограничен. Для этого применяется система мер по регистрации пользователей, т.е. идентификации и аутентификации, а также реализуется защита данных, ориентированная на регламентированный доступ к объектам данных (например, к таблицам, представлениям). Если же требуется сделать ограничение доступа к данным (например, к отдельным записям, полям в таблице), то в системе должны предусматриваться определенные средства (например, мандатная защита).

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

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

Процесс формализованного описания функциональных и нефункциональных требований, а также требований к характеристикам качества с учетом стандарта качества ISO/IEC 9126–94 будет уточняться на этапах ЖЦ ПО и специфицироваться. В спецификации требований отражается структура ПО, требования к функциям, качеству и документации, а также задается архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные, нефункциональные требования и требования к взаимодействию с другими компонентами и платформами (БД, СУБД, сеть и др.).

3.4. Трассирование требований

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

79

последовательно изменяются, благодаря чему их содержание и форма постепенно становятся более точными и полными, т.е. соответствуют действительности [6].

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

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

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

1)требования изменяются во время функционирования системы;

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

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

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

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

Механизмы трассировки должны учитывать следующее:

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

2)использовать сложные и гибкие пути трассировки;

3)поддержать базы данных объектов трассировки и отношений между ними.

Желательно наличие механизмов поддержки возможностей объектноориентированного программирования, операций над классами, а также механизмов унификации функций и отношений (1:1, 1:N, N:M), уничтожение и изменение связей, установка стандартных связей.

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

Человеческий фактор. Любой процесс постановки требований напрямую связан с умением людей контактировать друг с другом, кооперироваться или эффективно

80