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

Внимание !
Вопросы к тесту выложены исключительно в ознакомительных целях: количество вопросов может не совпадать с действительным, актуальность не поддерживается,- за решением теста Welcome to the cashier!

---

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

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


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

валидация требований
верификация требований
спецификация требований к ПО


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

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


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

снижение сложности
выявление требований
структуризация проверок
структура и архитектура ПО


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

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


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

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

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

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


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

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


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

определение процесса
управление процессом и проектом
количественный анализ процесса
инфраструктура процесса
инструменты инженерии ПО


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

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


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

эффективность
надежность
переносимость
стоимость
функциональность


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

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


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

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


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

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


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

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


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

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


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

организационное управление
концепции процесса инженерии ПО
управление процессом и проектом
количественный анализ процесса


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

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


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

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


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

проектирование ПО
инспекцию ПО
разработку ПО
валидацию ПО


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

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


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

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


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

схема проекта
компонентная организация проекта
архитектура проекта


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

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


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

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


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

CРM (Сritical Path Method)
PERT (Program Evaluation and Review Technique)
MPA (Management Process Activities)


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

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

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

тестирование ПО
сопровождение ПО
управление конфигурацией
процесс инженерии ПС
 

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

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

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

управление риском
управление качеством
организационное обеспечение
внедрение процессов


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

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


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

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


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

реинженерия
рефакторинг
реверсная инженерия


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

анализ требований
сбор требований
управление требованиями
систематизация требований


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

управление требованиями
инженерия требований
проверка требований


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

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

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

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


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

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

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

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


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

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


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

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


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

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


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

проблема - объект - сценарий - цель
проблема - сценарий - объект - цель
проблема - цель - сценарий - объект


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

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


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

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


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

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

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

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


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

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


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

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

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

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


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

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


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

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


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

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


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

извлечение требований
оценка качества
связь с процессами
спецификация требований


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

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


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

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


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

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


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

описание документа
согласование документа
техника обсуждения


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

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


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

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


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

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


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

use case сценарии или прецеденты
диаграммы активности
диаграммы классов


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

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

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

системных требований
функциональных требований
нефункциональных требований
несистемных требований

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

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


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

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

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

улучшение качества
систематизация требований
модель процессов ЖЦ
приемка требований
 

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

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


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

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


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

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


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

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


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

1
2
3


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

объектами одного или другого класса
атрибутами одного или другого класса
классами


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

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


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

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


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

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


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

концептуальное проектирование
абстрактное проектирование
техническое проектирование
детальное рабочее проектирование


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

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


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

алгоритмы задач
прикладные программные системы
интерфейсы с потенциальными пользователями системы
специфические бизнес-компоненты


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

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


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

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


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

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


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

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


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

диаграмма перехода состояний
график перехода состояний
таблица перехода в состояния


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

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


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

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


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

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


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

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


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

проектирование схемы интерфейсов системы
разработка концепции системы
проектирование эскизного, технического и рабочего проекта
формирование требований


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

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


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

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


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

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

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

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

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

на своем уровне или более верхнем
только на своем уровне
на своем уровне или более нижнем


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

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


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

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


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

распределенная
сосредоточенная
клиент-серверная
компонент-серверная


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

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


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

автоматизация ПС
модификация ПС
валидация ПС


UML - это:

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


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

private
projected
protected
primary
public
 

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

не может имеет интерфейсов
может иметь множество интерфейсов
может иметь только один интерфейс


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

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


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

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


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

пространство решений
пространство процессов
пространство проблемы


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

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


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

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


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

данные - функция - имя функции - композиция - дескрипция
данные - функция - имя функции - дескрипция - композиция
данные - имя функции - функция - дескрипция - композиция


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

<{АНС, L(2)}; СИГН>, где АНС - совокупность неструктурных схем, L(2) - совокупность различных булевских функций, СИГН - сигнатура из композиции A*B и операция неструктурного перехода П(u, F), а также операции дизъюнкции, конъюнкции и отрицания
{АСС, L(2), СИГН}, двухосновная алгебра, элементами которой являются множество АСС операторов, представленных структурными блок-схемами, множество L(2) булевых функций в сигнатуре СИГН, в которую входят операции дизъюнкции, конъюнкции и отрицания, принимающие значения из L(2)
{ОП, УС, СИГН}, где ОП и УС - множества операторов суперпозиции, входящих в сигнатуру СИГН, и логических условий, определенных на информационном множестве ИМ, СИГН={СИГНад Прогн.}, где СИГНад - сигнатура операций Дейкстры, Прогн. - операция прогнозирования


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

абстрагирование
непротиворечивость
экземпляризация
формализация


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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

принцип абстрактности
принцип прагматичности
принцип композиционности
принцип дескриптивности


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

<{АНС, L(2)}; СИГН>, где АНС - совокупность неструктурных схем, L(2) - совокупность различных булевских функций, СИГН - сигнатура из композиции A*B и операция неструктурного перехода П(u, F), а также операции дизъюнкции, конъюнкции и отрицания
{АСС, L(2), СИГН}, двухосновная алгебра, элементами которой являются множество АСС операторов, представленных структурными блок-схемами, множество L(2) булевых функций в сигнатуре СИГН, в которую входят операции дизъюнкции, конъюнкции и отрицания, принимающие значения из L(2)
{ОП, УС, СИГН}, где ОП и УС - множества операторов суперпозиции, входящих в сигнатуру СИГН, и логических условий, определенных на информационном множестве ИМ, СИГН={СИГНад Прогн.}, где СИГНад - сигнатура операций Дейкстры, Прогн. - операция прогнозирования


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

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


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

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


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

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

Внимание !
Вопросы к тесту выложены исключительно в ознакомительных целях: количество вопросов может не совпадать с действительным, актуальность не поддерживается,- за решением теста Welcome to the cashier!

---

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

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


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

полноту определений в программе
однозначность определений в программе
грамотность определений в программе
непротиворечивость определений в программе


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

E - интерфейс этого компонента с другими компонентами через передачу сообщений или вызовов процедур
E - исходный код компонента
E - множество типов сообщений компонента


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

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


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

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


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

разработка программ
верификация программ
выполнение программ


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

статические
динамические
логические


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

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


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

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


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

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


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

компоненты
группы компонентов
система
группы систем


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

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


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

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


Тест - это:

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


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

оценка тестов
создание тестовых сценариев
исправление ошибок, выявленных на этапе тестирования
составление плана теста
 

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

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


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

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


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

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

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

метод "черного ящика"
метод "серого ящика"
метод "белого ящика"


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

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


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

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


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

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


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

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

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

стратегии тестирования
состав тестировщиков ПС
ресурсы тестирования
график тестирования


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

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


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

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


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

внешним спецификациям функций
проектной информации
результатам работы функций
тексту на ЯП


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

метод "черного ящика"
метод "серого ящика"
метод "белого ящика"


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

аппаратный
информационный
программный
системный


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

оценка тестов
создание тестовых сценариев
исправление ошибок, выявленных на этапе тестирования
составление плана теста


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

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


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

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


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

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


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

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


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

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


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

систематические
статистические
имитационные
математические


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

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


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

алгоритмические
аппаратные
программные


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

он не наследует его операции
он наследует часть его операций
он наследует все его операции


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

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


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

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


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

интерфейса между Visual Basic
функций из Matlab
вызова приложения из среды


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

составные типы данных
сгенерированные типы данных
примитивные типы данных


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

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


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

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


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

транзитных файлов, в которые копируются данные из старой БД для переноса в новую БД
специального формата данных, в который конвертируются все переносимые данные из старой БД
специального драйвера (две СУБД соединяются друг с другом и напрямую передают данные, используя интерфейс


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

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


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

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


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

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


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

брокер ORB
компилятор IDL
метод RMI


Системы  и  для языков  и  - изоморфны, если их типы данных q, t:

определены на одном том же множестве простых или сложных типов данных
определены на разных множествах простых или сложных типов данных
не определены


XDR-стандарт:

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


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

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


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

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


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

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


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

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


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

замену одного из ЯП
отображение (mapping) неэквивалентного типа данных параметра в одном ЯП в соответствующий тип данных в другом ЯП
замену неэквивалентного типа данных


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

платформенно-ориентированных функций
функций в JNI
интерфейсных функций в С++


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

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


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

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


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

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


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

объект класса
внутреннее представление класса
внешнее представление класса


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

интерфейсных функций драйвера
программного интерфейса
интерфейса между Visual Basic
функций из Matlab


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

ЯП низкого уровня
LI-языке
абстрактном ЯП


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

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


XML-стандарт:

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


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

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

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

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

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

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


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

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


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

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


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

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


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

классы объектов и абстрактные классы
готовые решения в виде абстракций - паттерны, фреймы и др
алгоритмы, программы
коммерческие ОС


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

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


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

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


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

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


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

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


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

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


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

описание аспектов выполнения задач ПрО
корректировка процессов для разработки решений на основе ПИК
модель характеристик и набор компонентов реализации задач ПрО


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

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


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

они не имеют своих индивидуальных свойств
они не имеют общие свойства, а каждый член семейства имеет свои индивидуальные свойства
они имеют общие свойства, а каждый член семейства имеет свои индивидуальные свойства


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


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

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


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

прикладными
общесистемными
доменными


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

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


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

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


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

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


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

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


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

2 частей
3 частей
4 частей


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

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


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

обязательные
альтернативные
неальтернативные


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

трансляторы
электронная почта
системы генерации
ОС


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

интерфейс
реализацию
схему разработки


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

систему хранения ПИК
систему хранения, поиска и сопоставления ПИК
систему поиска и сопоставления ПИК


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

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


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

формирование ресурсов
разработка базы ресурсов
сопровождение ресурсов
управление ресурсами


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


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

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

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

компоненты ПИК
новые аспекты из семейства ПрО
классификацию моделей
сервисы и члены семейства ПС
аспекты взаимодействия, синхронизации компонентов
 

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


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

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


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

2
3
4
5


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

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


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

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


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

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


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

метрики размера
метрики надежности
метрики сложности
метрики стиля
метрики стоимости


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

метрических шкал
порядковых шкал
классификационных шкал


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

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


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

степени надежности носителей дан

Вы можете обратится к нам напрямую, через:

По Skype: molodoyberkut
По Telegram: @MolodoyBerkut
По ICQ: 657089516

Или через форму обратной связи на нашем сайте

Пока сочиняется...