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

Главная / Менеджмент /
Методы и средства инженерии программного обеспечения / Тест 3

Методы и средства инженерии программного обеспечения — тест 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. отношение «расширяет» означает, что функция одного сценария является дополнением к функции другого и используется при наличии нескольких вариантов одного и того же сценария (рис. 3.5).

   

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

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

   

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

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

Инженерия требований завершается построением модели требований, которая включает в себя:

1. описание требований и основных понятий ПрО;
2. модель сценариев;
3. интерфейсы сценариев.

Модель сценариев — это неформальное описание каждого из входящих в нее диаграмм сценариев.

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

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

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

На процессе проектирования ЖЦ выполняется преобразование трансформированного сценария в описание функциональных компонентов системы и проверка их правильности методом верификации.

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

3.2.2. Описание требований прецедентами

Альтернативным термином для сценария являются прецеденты. Как и в случае сценариев, задача описания требований прецедентами сводится к анализу дерева целей системы и к описанию реакции системы в случае недостижимости той или иной поставленной цели к проектируемой системе. Основным условием описания требований с помощью прецедентов является полнота системных требований, касающихся интерфейса пользователя, протоколов и форматов ввода-вывода [3.2,3.5].

Содержательной стороной системной части требований является описание функций, данных и принципов функционирования. Методология формирования требований с помощью прецедентов реализована в среде Rational Rose (www.rational.com.uml) и включает построение ряда моделей на основе прецедентов.

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

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

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

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

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

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

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

С синтаксической точки зрения эта модель имеет следующий вид.

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

Данный подход к представлению системы с помощью прецедентов задается в форме Vision-шаблонов [3.5].
Он применяется в офисной сфере, где деловой прецедент отражает представление этой сферы с внешней стороны, чтобы обеспечить субъекта требуемыми
результатами. При выполнении делового прецедента определяется взаимодействие деловой сферы и субъекта.
Совокупность деловых прецедентов устанавливает границы системы.

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

Контрольные вопросы и задания

1. Приведите классификацию требований.
2. Определите назначение функциональных и нефункциональных требований.
3. Назовите источники сведений для задания требований.
4. Приведите задачи обследования, анализа и сбора требований.
5. Определите инженерию требований.
6. Дайте определение спецификации требований.
7. Приведите задачи трассировки требований.
8. Определите сущность объектно-ориентированной инженерии требований.
9. Назовите роли действующих лиц формирования требований.
10. Определите понятие актора.
11. Назовите виды отношений объектов в модели.
12. Определите виды отношений в сценарном подходе.
13. Определите представление модели ПрО прецедентами.

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

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

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

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

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

• управление конфигурацией ПО
• валидацию ПО
• (Правильный ответ) инсталляцию ПО

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

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

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

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

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

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

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

• (Правильный ответ) процесс инженерии ПС
• (Правильный ответ) управление конфигурацией
• конструирование ПО
• инженерия требований

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

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

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

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

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

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

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

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

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

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

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

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

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

• (Правильный ответ) анализ требований
• систематизация требований
• сбор требований
• (Правильный ответ) управление требованиями

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

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

Класс — это:

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

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

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

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

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

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

• только на своем уровне
• на своем уровне или более нижнем
• (Правильный ответ) на своем уровне или более верхнем

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

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

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

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

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

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

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

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

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

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

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

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

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

• каждое состояние эквивалентно другой системе
• (Правильный ответ) каждое состояние эквивалентно состоянию другой системы
• каждое состояние неэквивалентно состоянию другой системы

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

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

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

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

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

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

UML — это:

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

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

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

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

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

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

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

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

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

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

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

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

• (Правильный ответ) оно проверено в среде этого компонента
• оно определено в среде этого компонента
• оно находится в среде этого компонента

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

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

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

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

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

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

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

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

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

• (Правильный ответ) исправление ошибок, выявленных на этапе тестирования
• оценка тестов
• создание тестовых сценариев
• составление плана теста

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

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

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

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

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

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

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

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

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

• (Правильный ответ) метод «белого ящика»
• метод «черного ящика»
• метод «серого ящика»

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

• (Правильный ответ) для каждого значения внутреннего типа данных преобразование определяет, является ли это значение образом (после преобразования) какого-то значения LI-типа данных и его способ преобразования
• (Правильный ответ) для каждого LI-типа данных преобразование определяет отношение между допустимым значением этого типа и эквивалентным значением соответствующего внутреннего типа ЯП
• для каждого внутреннего типа данных преобразование определяет связь между допустимым значением внутреннего типа данных и эквивалентным значением соответствующего LI-типа данных

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

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

XDR-стандарт:

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

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

• способность совместного, согласованного взаимодействия определенных компонентов системы для решения разнородных задач
• способность раздельного, несогласованного взаимодействия разнородных компонентов системы для решения определенной задачи
• (Правильный ответ) способность совместного, согласованного взаимодействия разнородных компонентов системы для решения определенной задачи

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

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

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

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

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

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

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

• (Правильный ответ)

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

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

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

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

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

• новые аспекты из семейства ПрО
• аспекты безопасности, защиты, изменения ПИК
• (Правильный ответ) определение области действий объектов ПрО
• компоненты ПИК

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

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

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

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

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

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

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

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

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

• простота
• универсальность
• быстродействие
• (Правильный ответ) надежность

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

• (Правильный ответ) среднее время между появлением угроз
• оптимальное время работы системы
• защищенность программы

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

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

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

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

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

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

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

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

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

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

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

• E = (a+bSc) m (X), где S — оценка размера системы, a, b, c — эмпирические константы, X[n] — вектор факторов стоимости, m — регулирующий множитель, основанный на затратных факторах
• E = 5.5 + 0.73 S1.16
• (Правильный ответ) E = 5.25 S0.91

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

• графическим представлением задач
• наличием информации о содержании работ
• (Правильный ответ) степенью сложности

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

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

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

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

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

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

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

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

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

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

Паттерн:

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

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

• физическ

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #