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

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

Правильные ответы выделены зелёным цветом.
Все ответы: В курсе представлено изложение ключевых понятий, методов и средств программной инженерии как деятельности, нацеленной на создание программных систем, отвечающих потребностям заказчиков, с соблюдением плановых сроков и бюджета.
Смотрите также:
Какими аспектами характеризуется качество ПО?
(1) качеством программного продукта
(2) качеством используемых аппаратных средств
(3) качеством процессов ЖЦ
(4) количеством претензий
(5) качеством сопровождения или внедрения
Какие задачи управления проектом входят на данный момент в диаграммную схему, созданную Генри Гантом для учета времени выполнения проекта?
(1) планирование проекта и составление графиков работ выполнения проекта
(2) проверка соответствия требований проектируемому продукту и критериев их достижения
(3) оценка показателей качества, заданных в требованиях на разработку ПС
(4) управление проектными работами и командой исполнителей
(5) управление рисками
Компонент - это:
(1) единица интеграции, специфицированная так, чтобы ее можно было объединять с другими компонентами в ПС
(2) код, который будет использоваться при обращении к операциям, определенным в интерфейсах компонента
(3) физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые операции и инструкции для создания, настройки и функционирования компонента
Главными областями программной инженерии являются:
(1) конструирование ПО
(2) управление проектами
(3) инженерия требований
(4) инженерия качества ПС
Разработка требований включает в себя следующие основные разделы:
(1) анализ требований
(2) сбор требований
(3) управление требованиями
(4) систематизация требований
Главная цель объектного анализа - это:
(1) построить архитектуру системы для анализируемой предметной области
(2) определить набор связей, которые имеют место между разными видами объектов предметной области
(3) представить предметную область как множество объектов со свойствами и характеристиками, которые достаточны для их определения и идентификации, а также для задания поведения объектов в рамках выбранной системы понятий и абстракций
К основным принципам структурного метода относятся:
(1) абстрагирование
(2) непротиворечивость
(3) экземпляризация
(4) формализация
Спецификация программы - это:
(1) описание, составленное в формальном языке и служащее способом проверки правильности программы в заданных точках
(2) точное, однозначное и недвусмысленное описание программы с помощью математических понятий, терминов, правил синтаксиса и семантики языка спецификации
(3) ограничение на совокупность входных и выходных параметров
Инструментальные средства - это:
(1) организационные средства планирования и отбора тестов для программ
(2) метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.)
(3) способы поддержки кодирования и тестирования (компиляторы, генераторы программ, отладчики и др.)
Виды интерфейсов включают в себя:
(1) языковые
(2) цифровые
(3) лингвистические
Инженерия повторного использования компонентов (ПИК) - это:
(1) процесс производства конкретных новых приложений из ПИК (модулей, программ, подпрограмм и др.), ранее созданных самостоятельно либо в среде программной системы или как отдельные элементы многоразового использования в инженерии другой ПрО
(2) систематическая и целенаправленная деятельность по подбору реализованных программных артефактов и представленных в виде ПИК, анализу их функций для добавления в качестве готовых в проектируемую систему и их интеграция с другими компонентами
(3) методы разработки, поиска, классификации, адаптации, сбора ПИК и создания из них или из готовых частей систем семейства домена, которые сохраняют наработанный опыт по реализации одного домена для применения его в другом крупном домене
Главный показатель качества ПО - это:
(1) быстродействие
(2) универсальность
(3) надежность
(4) простота
Основными составляющими любого проекта являются:
(1) ресурсы (людские, финансовые, технические)
(2) востребованность проекта
(3) время выполнения проекта
(4) стоимость выполнения проекта
Паттерн:
(1) определяет повторяемое решение в проблеме объединения компонентов в сложную структуру
(2) это общая структура, типовая для ряда систем с повторно возникающей ситуацией на уровне модели
(3) это оболочка, внутри которой реализуется функциональность компонента
Требования - это:
(1) высокоуровневое представление структуры системы и спецификация ее компонентов
(2) свойства, которыми должно обладать ПО для адекватного определения функций, условий и ограничений выполнения ПО, а также объемов данных, технического обеспечения и среды функционирования
(3) совокупность действий по обеспечению работы ПО
Разработка требований не включает в себя следующие основные разделы:
(1) управление требованиями
(2) инженерия требований
(3) проверка требований
Атрибут - это:
(1) абстракция набора связей, которые имеют место между разными видами объектов предметной области, абстрагированных как концепты
(2) абстракция, которой владеют все абстрагированные концепты сущности
(3) то, что анализируется с целью выделения специфичного множества понятий (сущностей, объектов) и связей между ними
Объектно-ориентированный подход (ООП) - это:
(1) парадигма построения гибких к изменению ПС путем добавления новых аспектов (функций), обеспечивающих безопасность и взаимодействие компонентов с другой средой
(2) стратегия разработки, в рамках которой разработчики системы вместо операций и функций мыслят объектами
(3) теория дескриптивных и декларативных программных формализмов, адекватных моделям структур данных
Дерево - это:
(1) конструкция map, позволяющая создавать абстрактную таблицу из двух столбцов: ключей и значений
(2) конструкция , позволяющая объединять структуры разной природы (последовательности, множества и отображения)
(3) цепочка элементов одинакового типа из множества X
Цель процесса верификации:
(1) убедиться, что специфические требования для программного продукта выполнены
(2) обнаружить ошибки в ПО путем исполнения выходного кода ПС на тестовых данных и сбора рабочих характеристик в динамике выполнения в конкретной операционной среде
(3) убедиться, что каждый программный продукт (и/или сервис) проекта отражает согласованные требования к их реализации
Интерфейс в ООП - это:
(1) объект класса
(2) внутреннее представление класса
(3) внешнее представление класса
Артефактами деятельности разработчиков ПС могут быть:
(1) готовые компоненты ПС или отдельные части системы
(2) интерфейсы ПС
(3) промежуточные продукты процесса разработки ПС
Функциональность - это:
(1) совокупность свойств, определяющих способность ПО выполнять определенный перечень функций, которые удовлетворяют потребностям в соответствии с назначением
(2) совокупность свойств, обусловливающая способность ПО сохранять работоспособность и преобразовывать исходные данные в результат за установленный период времени
(3) совокупность свойств ПО для предполагаемого круга пользователей и отражающих легкость его освоения и адаптации к изменяющимся условиям эксплуатации, стабильность работы и подготовки данных, понимаемость результатов, удобства внесения изменений в программную документацию и в программы
В ядре РМВОК определены следующие основные аспекты разработки проектов:
(1) методы постановки задачи (или анализа рынка ПО и конкурентоспособности продукта)
(2) методы управления, планирования и контроля работ
(3) эффективная организация проектной команды
(4) инструментарий менеджера проекта
Компоненты сеансов:
(1) поддерживают правила бизнеслогики, ориентированы на состояния и могут быть связаны с конкретным клиентским сеансом
(2) используются для связи с БД непосредственно и предоставляют данные в объектной форме
(3) функционируют для получения сообщений, поступающих от системы обмена сообщениями JMS (Java Messaging System), и реагируют на них
Проектирование ПО - это:
(1) процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта
(2) мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО
(3) создание работающего ПО с привлечением методов верификации, кодирования и тестирования компонентов
Требования к ПО состоят из:
(1) системных требований
(2) функциональных требований
(3) нефункциональных требований
(4) несистемных требований
Класс - это:
(1) семантически важный объект или тип объекта, существующий реально в предметной области
(2) совокупность точных определений понятий, концептов, объектов и их характеристик, а также множества синонимов и классифицированных логических взаимосвязей между эти-ми понятиями
(3) множество объектов, обладающих одинаковыми свойствами, операциями, отношениями и семантикой
UML - это:
(1) унифицированный язык моделирования
(2) универсальный многонациональный язык
(3) универсальный многовариантный язык
Отображение - это:
(1) структура (map), которая ставит в соответствие значениям одного типа значение другого типа
(2) конструктор union для объединения типов math, при котором тип id получает одно из значений в списке элементов
(3) последовательность значений одного типа listT
Методы функционального тестирования подразделяются на:
(1) статические
(2) динамические
(3) логические
Динамический интерфейс от объекта клиента к объекту сервера и обратно выполняет:
(1) брокер ORB
(2) компилятор IDL
(3) метод RMI
К общесистемным компонентам относятся:
(1) прикладные компоненты
(2) компоненты общего назначения
(3) компоненты универсальные назначения
(4) общесистемные сервисные средства
Сопровождаемость - это:
(1) группа свойств, определяющая усилия, необходимые для выполнения, приспособленность к диагностике отказов и последствий внесения изменений, модификации и аттестации модифицируемого ПО
(2) группа свойств, характеризующаяся степенью соответствия используемых ресурсов среды функционирования уровню качества (надежности) функционирования ПО при заданных условиях применения
(3) группа свойств ПО, обеспечивающая его приспособленность для переноса из одной среды функционирования в другие, усилия для переноса и адаптацию ПО к новой среде функционирования
Поддержка темпа работы не предполагает:
(1) постоянный контроль за использованием работниками рабочего времени
(2) уменьшение текучести кадров
(3) контроль качества выполняемых работ
(4) управление процессом разработки продукта, а не людьми команды
BlankAntProject - это:
(1) шаблон развертывания компонентов, создающий проект, который не содержит в себе ни одного класса или пакета классов, разрешающий подключать новые классы и пакеты в схему проекта
(2) шаблон развертывания компонентов, разрешающий сконфигурировать общую схему проекта с помощью иерархии системы файлов как корневой узел схемы нового проекта. Затем в проект добавляются новые компоненты, они пакетируются и делается их детальный просмотр
(3) шаблон развертывания компонентов, позволяющий создать новый проект, начиная с формирования первоначального класса в этом проекте
Конструирование ПО - это:
(1) процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта
(2) мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО
(3) создание работающего ПО с привлечением методов верификации, кодирования и тестирования компонентов
Требования пользователей определяют:
(1) перечень функций или сервисов, которые должна выполнять система, а также ограничений на данные и поведение системы
(2) цели и задачи, которые пользователям позволит решать будущая система
(3) внешние условия для выполнения системных функций и ограничений на создаваемый продукт, а также требования к описанию подсистем
Сколько этапов анализа предметной области в методе OOAS Шлеера и Меллора?
(1) 1
(2) 2
(3) 3
Атрибутами могут быть следующие типы значений в UML:
(1) private
(2) projected
(3) protected
(4) primary
(5) public
Декларативные средства КЯ - это:
(1) аксиомы и утверждения относительно концепторного описания и проведения дедуктивного доказательства и верификации этого описания
(2) типизированный, многосортный логикоматематический язык задания выражений и структуризации множества значений (денотат)
(3) операторы и процедуры для описания объектов ПрО с помощью концепторов, состоящих из разделов для определения объектов решаемой задачи и действий над ними
Статические методы тестирования используются:
(1) при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения
(2) при внедрении программы
(3) в процессе выполнения программ
Удаленный вызов разноязыковых программ предполагает:
(1) взаимно однозначное соответствие между фактическими параметрами math вызывающей программы и формальными параметрами math вызываемой программы
(2) композицию между фактическими параметрами math вызывающей программы и формальными параметрами math вызываемой программы
(3) обратное соответствие между фактическими параметрами math вызывающей программы и формальными параметрами math вызываемой программы
ПИК=(T,I,F,R,S), где T - это:
(1) реализация, скрытая часть - программный код
(2) тип компонента
(3) множество интерфейсов компонента
К подхарактеристикам надежности ПО не относится:
(1) безотказность
(2) устойчивость к ошибкам
(3) функциональная полнота
(4) восстанавливаемость
Сетевая разбивка работ (СРР) - это:
(1) иерархическая структура декомпозиции задач проекта на подзадачи, с расположением на нижнем уровне работ, детализированных на элементы деятельности
(2) линейная диаграмма, на которой задачи проекта представляются сроками в виде отрезков времени, включают даты начала и окончания выполнения задач с учетом возможных задержек или других временных параметров
(3) последовательность вех, определенных менеджером
Exception - это:
(1) шаблон для создания класса, его исключений и выдачи сообщений об ошибках, которые могут обнаружиться в программе
(2) шаблон, позволяющий отобразить реляционную схему и использовать ее для создания БД без подключения к MySQL
(3) шаблон, который помогает создать новый JAVA интерфейс и использовать его любым классом через ключевое слово implements
Тестирование ПО - это:
(1) процесс проверки готовой программы в статике и в динамике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными
(2) процесс проверки готовой программы только в статике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными
(3) процесс проверки готовой программы только в динамике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными
С какими целями проводится обсуждение проекта системы?
(1) в целях прогнозирования реальности его выполнения в заданные сроки и бюджет
(2) в целях выработки первых впечатлений и выводов относительно целесообразности выполнения проекта
(3) в целях выявления функций системы, которые должны быть реализованы в проекте
Атрибуты бывают:
(1) описательные
(2) вспомогательные
(3) указывающие
(4) дополнительные
Компонент, как физическая сущность:
(1) не может имеет интерфейсов
(2) может иметь множество интерфейсов
(3) может иметь только один интерфейс
Метод Флойда основан:
(1) на аксиоматическом описании семантики языка программирования исходных программ
(2) на структурной проверке функций, работающих над структурными типами данных, структур данных и диаграмм перехода во время символьного выполнения программ
(3) на определении условий для входных и выходных данных и в выборе контрольных точек в доказываемой программе так, чтобы путь прохождения по программе пересекал хотя бы одну контрольную точку
Динамические методы тестирования используются:
(1) при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения
(2) при внедрении программы
(3) в процессе выполнения программ
Интерфейс между Visual Basic и другими ЯП осуществляется с помощью:
(1) интерфейсных функций драйвера
(2) программного интерфейса
(3) интерфейса между Visual Basic
(4) функций из Matlab
Внутренняя часть компонента - это:
(1) интерфейс, который определяет взаимодействие компонента с внешней средой и с платформой, на которой он будет выполняться
(2) сервис для взаимодействия со средой или набор правил развертывания
(3) программный фрагмент кода, системная или абстрактная структура, представленные в виде каркаса компонента, спецификации и выходного кода
Метрики программного продукта включают:
(1) внешние метрики, обозначающие свойства продукта, видимые пользователю
(2) внутренние метрики, обозначающие свойства, видимые только команде разработчиков
(3) независимые метрики, обозначающие свойства, видимые только независимым экспертам
Организационная структура проекта подбирается на основании следующих данных:
(1) масштабность проекта
(2) рабочие стили членов группы
(3) число людей в группе
(4) стиль работы с заказчиками и разработчиками
Client class - это:
(1) шаблон интеграции компонентов в системе CORBA, для вызова метода, который будет выполнен сервером
(2) шаблон интеграции компонентов в системе CORBA, обеспечивает конвертирование данных метода, инициирующего работу клиента в Wire формате, используемом при связывании на стороне клиента сети
(3) шаблон интеграции компонентов в системе CORBA, управляет методами передачи данных и вызовами методов между процессами
Процесс сопровождения согласно стандарту ISO/IEC 14764 проводится путем:
(1) корректировки, т.е. изменения продукта для устранения обнаруженных ошибок или нереализованных задач
(2) адаптации, т.е. настройки продукта в изменившихся условиях эксплуатации или в новой среде выполнения данного ПО
(3) улучшения, т.е. эволюционного изменения продукта для повышения производительности или уровня сопровождения
(4) проверки ПО с целью поиска и исправления ошибок, обнаруженных при эксплуатации системы
В обсуждении требований на систему принимают участие:
(1) представители заказчика из нескольких профессиональных групп
(2) специалисты, производящие инсталляцию системы
(3) аналитики и разработчики будущей системы
Событие - это:
(1) множество состояний, в которых объект может находиться
(2) инцидент, который заставляет объект переходить из одного состояния в другое
(3) положение или ситуация объекта, определяемая правилами и линией поведения
Аспектно-ориентированное программирование (АОП) - это:
(1) парадигма построения гибких к изменению ПС путем добавления новых аспектов (функций), обеспечивающих безопасность и взаимодействие компонентов с другой средой
(2) стратегия разработки, в рамках которой разработчики системы вместо операций и функций мыслят объектами
(3) теория дескриптивных и декларативных программных формализмов, адекватных моделям структур данных
Валидация требований - это:
(1) проверка полноты, непротиворечивости и однозначности спецификации и правильности выполнения функций системы в соответствии с требованиями
(2) процесс выявления ошибок в представлении сценарных требований
(3) заключение о корректности созданной программной системы после завершения ее разработки
В задачи функционального тестирования входят:
(1) идентификация множества функциональных требований
(2) выделение объектов тестирования
(3) построение тестовых наборов и сценариев тестирования функций
(4) анализ результатов тестирования
Независимые от ЯП типы данных стандарта ISO/IEC 11404-1996 делятся на:
(1) примитивные типы данных
(2) сгенерированные типы данных
(3) типы данных высокого уровня
Развертка - это:
(1) код, который будет использоваться при обращении к операциям, определенных в интерфейсах компонента
(2) физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые операции и инструкции для создания, настройки и функционирования компонента
(3) абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность
Оценка качества ПО согласно четырехуровневой модели качества начинается с:
(1) нижнего уровня иерархии
(2) верхнего уровня иерархии
(3) оценки уровня тестируемости
Какая формула оценки стоимости проекта была получена экспериментальным путем?
(1) E = (a+bSc) m (X), где S - оценка размера системы, a, b, c - эмпирические константы, X[n] - вектор факторов стоимости, m - регулирующий множитель, основанный на затратных факторах
(2) E = 5.25 S0.91
(3) E = 5.5 + 0.73 S1.16
Implementation class - это:
(1) шаблон интеграции компонентов в системе CORBA, содержит деловую логику сервера, экземпляр этого класса сервент регистрируется в ORB и может использоваться клиентом для запуска другого процесса
(2) шаблон интеграции компонентов в системе CORBA, создает сервент и ссылку IOR, которую он записывает в стандартный выходной файл
(3) шаблон интеграции компонентов в системе CORBA, конвертирует инициирующий метод с Wire форматом в формат, который может прочитать экземпляр сервента
Область знаний "Управление конфигурацией ПО" включает в себя следующие разделы:
(1) идентификация конфигурации ПО
(2) аудит конфигурации ПО
(3) управление процессом конфигурации
(4) управление версиями ПО и доставкой
Управление требованиями к системе - это:
(1) руководство процессами формирования требований на всех этапах ЖЦ, которое не включает управление изменениями требований, отражающих свойства программного продукта, а также восстановление источника требований
(2) руководство процессами управления изменениями требований, отражающих свойства программного продукта
(3) руководство процессами формирования требований на всех этапах ЖЦ, которое включает управление изменениями требований, отражающих свойства программного продукта, а также восстановление источника требований
Таблица перехода в состояния служит для:
(1) наглядности и определенности действий
(2) обеспечения полноты и непротиворечивости заданных требований к системе
(3) фиксации всех возможных комбинаций состояние/событие
Технология разработки прикладной системы с использованием АОП включает следующие общие этапы:
(1) выбор готовых компонентов с подобными функциями, пригодными для практического применения и настройка их к новым условиям
(2) определение механизмов композиции функциональных модулей многоразового применения и аспектов в точках их соединения
(3) анализ библиотеки расширений для выбора некоторых функциональных модулей, необходимых для реализации задач ПрО
(4) декомпозиция функциональных задач с условием многоразового применения модулей и выделенных аспектов
Методы анализа структуры программ проверяют:
(1) полноту определений в программе
(2) однозначность определений в программе
(3) грамотность определений в программе
(4) непротиворечивость определений в программе
Под инфраструктурой процесса тестирования понимается:
(1) выделение объектов тестирования
(2) функциональные требования
(3) подготовка тестов, их выполнение и поиск разного рода ошибок и отказов в компонентах и в системе в целом
(4) текст программы на ЯП
(5) анализ результатов тестирования
Каждый тип данных в стандарте имеет шаблон, включающий:
(1) значение в пространстве значений
(2) операции над типами данных
(3) описание и спецификатор типа данных
(4) синтаксическое описание
(5) функциональное описание
Репозитарий - это:
(1) система средств для хранения, пополнения наработанных ПИК, включает инфраструктуру разработки ПС из компонентов и организацию доступа к содержащимся в нем ПИК для последующего их применения в новых проектах
(2) система средств для хранения, пополнения наработанных ПИК, не включает инфраструктуру разработки ПС из компонентов и организацию доступа к содержащимся в нем ПИК для последующего их применения в новых проектах
(3) система средств для хранения, пополнения наработанных ПИК, включает инфраструктуру разработки ПС из компонентов
При подходе, ориентированном на продукт, оценка качества проводится после испытания ПС. Этот подход базируется на предположении, что:
(1) чем быстрее проведены испытания продукта, тем выше его качество
(2) чем меньше обнаружено и устранено ошибок в процессе испытания продукта, тем выше его качество
(3) чем больше обнаружено и устранено ошибок в продукте при испытаниях, тем выше его качество
Под конфигурацией системы понимается:
(1) конкретная версия ПС для разных ОС, компьютеров
(2) состав и количество сотрудников, входящих в команду проекта
(3) объем работ, имеющиеся ресурсы и ограничения
Stub-интерфейс - это:
(1) интерфейс клиента, содержащий описание внешне видимых параметров и операций объекта в IDL-языке; обеспечивает взаимосвязь клиента с ORB
(2) интерфейс клиента, определяемый во время выполнения программы клиента, используя описание интерфейса из репозитария интерфейсов; обеспечивает доступ (извлечение) к объектам и их интерфейсам во время выполнения
(3) интерфейс клиента, содержащий набор сервисных функций, которые клиент запрашивает у сервера через брокера
Область знаний "Управление инженерией ПО" состоит из следующих разделов:
(1) организационное управление
(2) инженерия проектирования ПО
(3) управление процессом и проектом
(4) инженерия измерений ПО
Фиксация требований включает в себя подразделы:
(1) спецификация требований
(2) сбор требований
(3) согласование документа
(4) трассирование требований
(5) систематизация требований
Задачи проектирования - это:
(1) построение архитектуры системы
(2) анализ и формирование требований
(3) преобразование требований к системе в требования к ПО
Генерирующее программирование - это:
(1) парадигма построения гибких к изменению ПС путем добавления новых аспектов (функций), обеспечивающих безопасность и взаимодействие компонентов с другой средой
(2) стратегия разработки, в рамках которой разработчики системы вместо операций и функций мыслят объектами
(3) генерация семейств приложений из отдельных элементов компонентов, аспектов, сервисов, ПИК, каркасов
Основные систематические методы обеспечения правильности программ - это:
(1) верификация компонентов
(2) верификация требований
(3) валидация требований
(4) валидация компонентов
В соответствии с международным стандартом ANSI/IEEE-729-83 ошибка (error) - это:
(1) следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п.
(2) состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки
(3) отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями
Маршалинг данных - это:
(1) преобразование данных к формату данных принимающей серверной платформы
(2) преобразование данных к формату данных передавшей клиентской программы
(3) прямое и обратное преобразование данных средствами ЯП
ПС, построенная из компонентов и предназначенная для функционирования в распределенной среде, состоит из:
(1) 2 частей
(2) 3 частей
(3) 4 частей
Оценка надежности сложных ПС зависит от:
(1) степени надежности носителей данных
(2) числа оставшихся и не устраненных ошибок в программах
(3) длительности эксплуатации
Базис конфигурации - это:
(1) формально созданная основа (версия) системы из отдельных компонентов и документации, позволяющая проводить дальнейшее развитие системы
(2) элементы конфигурации, выделенные для управления или обработки функций системы на процессорах компьютеров системы
(3) программные компоненты, выполняющие задачи в сформированной версии системы
К объектным адаптерам, позволяющим экземплярам объектов обращаться к сервисным функциям ORB, не относится:
(1) базовый адаптер
(2) библиотечный адаптер
(3) промежуточный адаптер
(4) адаптер БД
Область знаний "Процесс программной инженерии" состоит из следующих разделов:
(1) определение процесса
(2) управление процессом и проектом
(3) количественный анализ процесса
(4) инфраструктура процесса
(5) инструменты инженерии ПО
Типы трассируемости требований включают в себя следующие направления:
(1) от потребностей к требованиям
(2) от потребностей к рабочим продуктам
(3) от требований к потребностям
(4) от рабочих продуктов к требованиям
Этапами стандарта ГОСТ 34.601-90, регламентирующего стадии и этапы процесса разработки АС, являются:
(1) проектирование схемы интерфейсов системы
(2) разработка концепции системы
(3) проектирование эскизного, технического и рабочего проекта
(4) формирование требований
Агент обладает следующими свойствами:
(1) защищенность
(2) распределенность
(3) автономность
(4) реактивность
(5) активность
К событиям процесса относятся:
(1) отправка сообщения в канал
(2) нахождение сообщения в канале
(3) получение сообщения из канала
(4) анализ непредвиденного события
(5) чистка входных и выходных каналов
В соответствии с международным стандартом ANSI/IEEE-729-83 отказ (failure) - это:
(1) следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п.
(2) состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки
(3) отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями
Преобразование данных БД связано с различием логических структур данных, а также со следующими проблемами:
(1) различия в логических структурах данных, в справочниках, классификаторах и в системах кодирования информации
(2) различия на этапе разработки СУБД
(3) многомодельность представления данных (иерархические, сетевые, реляционные) в различных БД и СУБД
В основе генерации модели ПрО для семейства ПС лежит:
(1) описание аспектов выполнения задач ПрО
(2) корректировка процессов для разработки решений на основе ПИК
(3) модель характеристик и набор компонентов реализации задач ПрО
Отказ ПC - это:
(1) переход ПС из работающего состояния в нерабочее или когда получаются результаты, которые не соответствуют заданным допустимым значениям
(2) следствие ошибок разработчика на любом из процессов разработки
(3) частота появления отказов или дефектов в ПС при ее тестировании или эксплуатации
Управление конфигурацией - это:
(1) именование всех элементов системы на основе схемы классификации и кодирования элементов, а также методов представления и ведения версий конфигурации с использованием входящих в нее элементов
(2) проверка и управление изменениями системы при формировании версии и эксплуатации
(3) процесс, обеспечивающий идентификацию элементов конфигурации системы при ее создании для проведения систематического контроля, учета и аудита внесенных изменений, а также для поддержки целостности и работоспособности системы
RUP (Rational Unified Process) - это:
(1) процесс моделирования и построения ПС из объектов с применением языка UML
(2) деятельность, направленная на определение целей и требований к качеству
(3) руководство работами команды исполнителей проекта для реализации проекта с использованием методов управления, планирования и контроля работ
Методы инженерии ПО - это:
(1) эвристические методы
(2) методы прототипирования
(3) методы программрования
(4) формальные методы
Основные средства UML к формированию и представлению требований к системе и к ПО - это:
(1) use case сценарии или прецеденты
(2) диаграммы активности
(3) диаграммы классов
Взаимодействие объектов - это:
(1) выполнение одним объектом функций другого объекта
(2) изменение атрибутов одного объекта другим объектом
(3) обмен сообщениями между элементами системы
Алгебраическое программирование - это:
(1) парадигма построения гибких к изменению ПС путем добавления новых аспектов (функций), обеспечивающих безопасность и взаимодействие компонентов с другой средой
(2) конструирование программ с алгебраическими преобразованиями и функциями интеллектуальных агентов
(3) генерация семейств приложений из отдельных элементов компонентов, аспектов, сервисов, ПИК, каркасов
Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:
(1) E - интерфейс этого компонента с другими компонентами через передачу сообщений или вызовов процедур
(2) E - исходный код компонента
(3) E - множество типов сообщений компонента
Тест - это:
(1) некоторая программа, предназначенная для проверки работоспособности другой программы и обнаружения в ней ошибочных ситуаций
(2) генератор тестовых данных
(3) спецификация требований
Типичные причины внесения изменений это:
(1) изменение условий заказчиком, которые связаны с корректировкой ранее поставленных им требований
(2) желание заказчика отказаться от старой системы и получить новую систему
(3) выявление дефектов в системе во время эксплуатации, которые не были обнаружены на этапе тестирования
Анализ домена состоит в:
(1) создании репозитария домена
(2) описании аспектов домена
(3) определении границ домена и связей с другими доменами
(4) классификации и документировании моделей
Прогнозирующие модели надежности:
(1) основаны на измерении технических характеристик создаваемой программы: длина, сложность, число циклов и др.
(2) предназначены для измерения надежности программного обеспечения, работающего с заданной внешней средой
(3) основываются на серии тестовых прогонов и проводятся на этапах тестирования ПC
Управление версиями состоит в:
(1) интеграции или композиции корректной и окончательной версии системы из элементов конфигурации, реализованных на этапах ЖЦ, а также с учетом аппаратных средств и инструментов построения системы
(2) выборе инструментов построения версии, оценке возможностей среды и средств автоматизации процесса построения отдельных версий с корректной конфигурацией ПО и данных
(3) управлении вариантами версий, включающими совокупность готовых идентифицированных элементов системы и удовлетворяющих заданным требованиям заказчика к варианту
(4) определении стратегии идентификации для получения учтенной версии системы
Модель процесса разработки ПО - это:
(1) модель, определяющая структуру процессов и руководство ими в течение всего времени жизни проекта
(2) модель, с помощью которой определяется порядок и условия реализации упреждающих решений и мер по выявлению наиболее существенных моментов риска
(3) модель, определяющая цели и задачи процесса разработки производственной архитектуры с параллельным и итерационным выполнением отдельных работ
Качество ПО - это:
(1) степень автоматизированного выполнения задач процессов жизненного цикла
(2) стоимость работ по проектированию и разработке ПО
(3) набор свойств продукта, которые характеризуют его способность удовлетворить установленные или предполагаемые потребности заказчика
Отношение между сценариями "расширяет" означает, что:
(1) некоторый сценарий может быть использован как расширение нескольких других сценариев
(2) функция одного сценария является дополнением к функции другого и используется при наличии нескольких вариантов одного и того же сценария
(3) некоторый сценарий может быть использован как расширение только одного другого сценария
Создаваемая архитектура системы не включает в себя следующие уровни:
(1) алгоритмы задач
(2) прикладные программные системы
(3) интерфейсы с потенциальными пользователями системы
(4) специфические бизнес-компоненты
Процесс развития программы в ЭП осуществляется в виде цепочки понятий:
(1) данные - функция - имя функции - композиция - дескрипция
(2) данные - функция - имя функции - дескрипция - композиция
(3) данные - имя функции - функция - дескрипция - композиция
При использовании модели проверки временных свойств и обнаружения ошибок взаимодействия должны выполняться следующие условия:
(1) семантика выполнения процесса определяется в терминах событий и правил
(2) спецификация компонентов задается в языке диалекта UML и содержит описание временных свойств
(3) reuse-компоненты задают функции, спецификации интерфейса и временные свойства
(4) композиционный аппарат проверяет свойства составных компонентов
(5) абстракция компонента составлена из примитива и проверенных свойств в интегрированной среде
План тестирования содержит:
(1) стратегии тестирования
(2) состав тестировщиков ПС
(3) ресурсы тестирования
(4) график тестирования
Реинженерия (reengineering) - это:
(1) эволюция программы путем ее изменения в целях повышения удобства ее эксплуатации, сопровождения или изменения ее функций
(2) внесение изменений в компоненты или интерфейсы (добавление, расширение и т. д. ), добавление экземпляров компонентов, новых функций или системных сервисов
(3) полная переделка компонентов, а иногда и перепрограммирование всей системы
Свойства ПИК могут быть:
(1) обязательные
(2) альтернативные
(3) неальтернативные
Модель Шика-Вулвертона:
(1) базируется на выявлении отказов и моделируется неоднородным процессом
(2) характеризуется дискретным временем и конечным множеством состояний
(3) используется тогда, когда интенсивность отказов пропорциональна не только текущему числу ошибок, но и времени, прошедшему с момента последнего отказа
Суть учета статуса состоит в:
(1) регистрации и предоставлении информации для эффективного управления конфигурацией
(2) ревизии или проверке очередной версии ПО перед сдачей системы заказчику
(3) рассмотрении и оценке документации
Модель производственной архитектуры - это:
(1) набор принципов, обеспечивающих создание версии производственной архитектуры предприятия
(2) модель, определяющая роли, обязанности каждого участника проекта и распределение между ними ответственности
(3) трехуровневая структура, сценарный метод проектирования и разработки приложения
Категория "Процессы поддержки" процессов жизненного цикла в стандарте ISO/IEC 12207 не включает в себя:
(1) управление конфигурацией ПО
(2) инсталляцию ПО
(3) валидацию ПО
Модель прецедентов моделируемой цели системы состоит из:
(1) основных действующих лиц и их целей
(2) фрагментов диаграммы последовательности и конструкций потока управления
(3) требований к форматам и протоколам взаимодействия
(4) требований к тестированию и к процедуре развертывания системы у заказчика
Компоненты любого из уровней архитектуры системы используются, как правило:
(1) на своем уровне или более верхнем
(2) только на своем уровне
(3) на своем уровне или более нижнем
Алгебра Дейкстры - это:
(1) <{АНС, L(2)}; СИГН>, где АНС - совокупность неструктурных схем, L(2) - совокупность различных булевских функций, СИГН - сигнатура из композиции A*B и операция неструктурного перехода П(u, F), а также операции дизъюнкции, конъюнкции и отрицания
(2) {АСС, L(2), СИГН}, двухосновная алгебра, элементами которой являются множество АСС операторов, представленных структурными блок-схемами, множество L(2) булевых функций в сигнатуре СИГН, в которую входят операции дизъюнкции, конъюнкции и отрицания, принимающие значения из L(2)
(3) {ОП, УС, СИГН}, где ОП и УС - множества операторов суперпозиции, входящих в сигнатуру СИГН, и логических условий, определенных на информационном множестве ИМ, СИГН={СИГНад∪Прогн.}, где СИГНад - сигнатура операций Дейкстры, Прогн. - операция прогнозирования
Международный проект по разработке "целостного автоматизированного набора инструментов для проверки корректности ПС" включает следующие основные задачи:
(1) создание репозитария формальных спецификаций и верифицированных программных объектов разных видов и типов
(2) построение всеобъемлющего интегрированного набора инструментов верификации для всех производственных этапов, включая разработку спецификаций и их проверку, генерацию тестовых примеров, уточнение, анализ и верификацию программ
(3) разработка единой системы проверки корректности ПС
(4) разработка единой теории построения и анализа программ
Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 включает:
(1) описание задач, назначение и содержание ПС, а также перечень функций в соответствии с требованиями заказчика
(2) технологии разработки системы
(3) описание внутренних структурных и программных особенностей системы
Метод рефакторинга компонента - это:
(1) целевое средство получения нового компонента путем выполнения последовательности операций внесения изменений, модернизации или модификации, а также перепрограммирования отдельных компонентов ПС
(2) целевой способ получения нового компонента на базе существующего, который включает операции модификации (изменение, замещение, расширение) компонентов и интерфейсов
(3) разработанный в среде объектно-ориентированного программирования метод, базирующийся на выполнении базовых операций визуализации (visual) и измерения метрик (metric) ПС в рамках модели
Стоимость анализа функций ПрО имеет вид:
(1) math
(2) math
(3) math
Требования, предъявляемые к качеству ПО, ставятся в соответствии с:
(1) условиями применения
(2) профессионализмом программистов
(3) конкретной областью применения
(4) сложностью решаемых задач
Управление проектом - это:
(1) руководство работами команды исполнителей проекта для реализации проекта с использованием методов управления, планирования и контроля работ, управление рисками, эффективной организацией работы и коммуникационными потоками в команде исполнителей
(2) процесс распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта
(3) совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС
Важнейшее свойство компонента:
(1) отделение реализации класса от определения класса
(2) отделение его интерфейса от реализации
(3) независимость от ЖЦ разработки ПС
Организационными областями программной инженерии являются:
(1) тестирование ПО
(2) сопровождение ПО
(3) управление конфигурацией
(4) процесс инженерии ПС
Раздел "Анализ требований" разработки требований включает в себя следующие подразделы:
(1) анализ требований
(2) сбор требований
(3) техника обсуждения
(4) валидация требований
Объект предметной области - это:
(1) значение некоторой абстрактной сущности предметной области
(2) абстрактный образ с поведением, которое обусловлено его характеристиками и взаимоотношениями с другими объектами предметной области
(3) конкретный образ с поведением, которое обусловлено его характеристиками и взаимоотношениями с другими объектами предметной области
Абстрагирование - это:
(1) выделение существенных аспектов системы и отвлечение от несущественных
(2) общее методологическое решение проблемы
(3) организация составных частей проблемы в древовидные структуры с добавлением новых деталей на каждом уровне
Категории языков спецификации включают в себя:
(1) универсальный язык спецификации
(2) язык спецификации предметных областей
(3) язык описания предметных областей
(4) язык описания утверждений
Теоретические средства - это:
(1) организационные средства планирования и отбора тестов для программ
(2) методы верификации и доказательства правильности спецификации программ
(3) метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.)
Программный (API) и/или аппаратный интерфейс (port) - это:
(1) программа или часть программы, в которой определяются константы, переменные, параметры и структуры данных для передачи другим
(2) набор операций, обеспечивающих определение видов услуг и способов их получения от программного объекта, предоставляющего эти услуги
(3) способы преобразования входных/выходных данных во время объединения компьютера с периферийным оборудованием
Процесс создания ПИК включает в себя:
(1) изучение спектра решаемых задач ПрО, выявление среди них общих свойств и функций
(2) поиск в каталоге готовых компонентов, которые кажутся подходящими для их использования в новой системе
(3) интеграцию ПИК в новую разработку с обеспечением интерфейса с подсистемами и другими компонентами
(4) разработку каталога для хранения изготовленных компонентов и организации поиска необходимых компонентов по запросам пользователей
Сколько уровней представления имеет модель качества ПО?
(1) 2
(2) 3
(3) 4
(4) 5
Ответственность за координацию и реализацию основных составляющих проекта несет:
(1) менеджер проекта
(2) главный программист
(3) системный администратор
Каркас
(1) определяет повторяемое решение в проблеме объединения компонентов в сложную структуру
(2) это общая структура, типовая для ряда систем с повторно возникающей ситуацией на уровне модели
(3) это оболочка, внутри которой реализуется функциональность компонента
Валидация требований - это:
(1) процесс формализованного описания функциональных и нефункциональных требований
(2) процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам
(3) проверка изложенных в спецификации требований, выполняющаяся для того, чтобы путем отслеживания источников требований убедиться, что они определяют именно данную систему
Инженерия требований включает в себя следующие подразделы:
(1) улучшение качества
(2) систематизация требований
(3) модель процессов ЖЦ
(4) приемка требований
Отношение - это:
(1) абстракция набора связей, которые имеют место между разными видами объектов предметной области, абстрагированных как концепты
(2) абстракция, которой владеют все абстрагированные концепты сущности
(3) то, что анализируется с целью выделения специфичного множества понятий (сущностей, объектов) и связей между ними
Процесс разработки в среде ООП включает в себя следующие этапы:
(1) сопровождение
(2) проектирование
(3) модификация ПС
(4) программирование
(5) анализ
Отображение - это:
(1) конструкция map, позволяющая создавать абстрактную таблицу из двух столбцов: ключей и значений
(2) конструкция , позволяющая объединять структуры разной природы (последовательности, множества и отображения)
(3) цепочка элементов одинакового типа из множества X
Цель процесса валидации:
(1) убедиться, что специфические требования для программного продукта выполнены
(2) обнаружить ошибки в ПО путем исполнения выходного кода ПС на тестовых данных и сбора рабочих характеристик в динамике выполнения в конкретной операционной среде
(3) убедиться, что каждый программный продукт (и/или сервис) проекта отражает согласованные требования к их реализации
Интерфейсные операции класса подразделяются на:
(1) публичные, доступные всем клиентам
(2) клиентские, различные для разных клиентов
(3) защищенные, доступные классу и подклассу
(4) приватные, доступные классу
Разработке ПС с помощью ПИК соответствует модель ЖЦ со следующими общими этапами:
(1) интеграция ПИК и их интерфейсов с другими элементами создаваемой системы и формирование конфигурации этой системы
(2) оценка эффективности вложения капитала при инвестициях в ПИК
(3) анализ объектов и отношений реализуемой ПрО для выявления ПИК, обладающих общими свойствами, присущими группам объектов этой области
(4) разработка интерфейсов компонентов и их размещение в репозитарии интерфейсов системы
Надежность - это:
(1) группа свойств ПО, обуславливающая его способность выполнять определенный перечень функций, которые удовлетворяют потребностям в соответствии с назначением
(2) группа свойств, обусловливающая способность ПО сохранять работоспособность и преобразовывать исходные данные в результат за установленный период времени, характер отказов которого является следствием внутренних дефектов и условий его применения
(3) совокупность свойств ПО для предполагаемого круга пользователей и отражающих легкость его освоения и адаптации к изменяющимся условиям эксплуатации, стабильность работы и подготовки данных, понимаемость результатов, удобства внесения изменений в программную документацию и в программы
Чем отличается метод анализа и оценки PERT от метода критического пути CPM?
(1) графическим представлением задач
(2) наличием информации о содержании работ
(3) степенью сложности
Компоненты сущностей:
(1) поддерживают правила бизнеслогики, ориентированы на состояния и могут быть связаны с конкретным клиентским сеансом
(2) используются для связи с БД непосредственно и предоставляют данные в объектной форме
(3) функционируют для получения сообщений, поступающих от системы обмена сообщениями JMS (Java Messaging System), и реагируют на них
Высокоуровневое представление структуры системы и спецификация ее компонентов - это:
(1) схема проекта
(2) компонентная организация проекта
(3) архитектура проекта
Нефункциональные требования для большинства современных многопользовательских ПС включают следующие условия и ограничения:
(1) конфиденциальность, безопасность и защита данных
(2) одновременность доступа к системе пользователей
(3) стоимость системы
(4) отказоустойчивость
(5) производительность
Сущность - это:
(1) семантически важный объект или тип объекта, существующий реально в предметной области
(2) совокупность точных определений понятий, концептов, объектов и их характеристик, а также множества синонимов и классифицированных логических взаимосвязей между эти-ми понятиями
(3) множество объектов, обладающих одинаковыми свойствами, операциями, отношениями и семантикой
Диаграмма последовательности задает:
(1) поведение совокупности объектов, функции которых ориентированы на достижение целей системы, а также взаимосвязи тех ролей, которые обеспечивают сотрудничество
(2) взаимодействие объектов с помощью сценариев, отображающих события, связанные с их созданием и уничтожением
(3) поведение системы в виде определенных работ, которые может выполнять система или актер, виды работ могут зависеть от принятия решений в зависимости от заданных условий или ограничений
Объединение - это:
(1) структура (map), которая ставит в соответствие значениям одного типа значение другого типа
(2) конструктор union для объединения типов math, при котором тип id получает одно из значений в списке элементов
(3) последовательность значений одного типа listT
Отладка - это:
(1) проверка описания программного объекта на ЯП с целью обнаружения в нем ошибок без последующего их устранения
(2) описание программного объекта на ЯП, проверка созданного описания с целью обнаружения в нем ошибок и последующее их устранение
(3) проверка описания программного объекта на ЯП с целью обнаружения в нем ошибок и последующее их устранение
В функции интерфейсного посредника клиента не входит:
(1) посылка параметров серверу и его запуск в целях получения результата или сведений об ошибке
(2) возврат результата клиенту через параметры сообщения
(3) подготовка внешних параметров клиента для обращения к сервису сервера
На современном рынке программных продуктов циркулируют следующие виды готовых компонентов:
(1) классы объектов и абстрактные классы
(2) готовые решения в виде абстракций - паттерны, фреймы и др
(3) алгоритмы, программы
(4) коммерческие ОС
Рациональность - это:
(1) группа свойств, определяющая усилия, необходимые для выполнения, приспособленность к диагностике отказов и последствий внесения изменений, модификации и аттестации модифицируемого ПО
(2) группа свойств, характеризующаяся степенью соответствия используемых ресурсов среды функционирования уровню качества (надежности) функционирования ПО при заданных условиях применения
(3) группа свойств ПО, обеспечивающая его приспособленность для переноса из одной среды функционирования в другие, усилия для переноса и адаптацию ПО к новой среде функционирования
Управление процессом разработки состоит в:
(1) формировании команды разработчиков из хороших специалистов
(2) анализе проектирования элементов системы и критике результатов труда исполнителей, а не режима работы
(3) изучении своих ошибок при реализации предыдущего проекта, чтобы не повторить их в новом проекте
SampleAntProject - это:
(1) шаблон развертывания компонентов, создающий проект, который не содержит в себе ни одного класса или пакета классов, разрешающий подключать новые классы и пакеты в схему проекта
(2) шаблон развертывания компонентов, разрешающий сконфигурировать общую схему проекта с помощью иерархии системы файлов как корневой узел схемы нового проекта. Затем в проект добавляются новые компоненты, они пакетируются и делается их детальный просмотр
(3) шаблон развертывания компонентов, позволяющий создать новый проект, начиная с формирования первоначального класса в этом проекте
Выберите верные утверждения:
(1) формальный стиль конструирования используется для точного, однозначного и формального определения компонентов системы
(2) визуальный стиль конструирования является наименее универсальным стилем конструирования ПО. При применении визуального стиля конструирования создается только текстовое описание конструктивных элементов ПО
(3) лингвистический стиль конструирования используется при конструировании несложных конструкций и приводится к виду традиционных функций и процедур, логическому и функциональному их программированию и др.
Функциональные требования определяют:
(1) перечень функций или сервисов, которые должна выполнять система, а также ограничений на данные и поведение системы
(2) цели и задачи, которые пользователям позволит решать будущая система
(3) внешние условия для выполнения системных функций и ограничений на создаваемый продукт, а также требования к описанию подсистем
Согласно методу OOAS Шлеера и Меллора, анализ предметной области производится следующими этапами:
(1) моделирование состояний
(2) аналитическое моделирование
(3) проектирование процессов
(4) моделирование процессов
(5) информационное моделирование
Ассоциация - это:
(1) зависимость между объектами разных классов, каждый из которых является равноправным ее членом
(2) совокупность диаграмм, которые визуализируют основные элементы структуры системы
(3) зависимость между параметризированным абстрактным классом-шаблоном и реальным классом, который инициирует параметры шаблона
Императивные средства КЯ - это:
(1) аксиомы и утверждения относительно концепторного описания и проведения дедуктивного доказательства и верификации этого описания
(2) типизированный, многосортный логикоматематический язык задания выражений и структуризации множества значений (денотат)
(3) операторы и процедуры для описания объектов ПрО с помощью концепторов, состоящих из разделов для определения объектов решаемой задачи и действий над ними
Инспекция ПО - это:
(1) статическая проверка соответствия программы заданным спецификациями
(2) динамическая проверка соответствия программы заданным спецификациями
(3) функциональная проверка соответствия программы заданным спецификациями
При неоднородности одного из параметров из множества формальных или фактических параметров разноязыковых программ необходимо провести:
(1) замену одного из ЯП
(2) отображение (mapping) неэквивалентного типа данных параметра в одном ЯП в соответствующий тип данных в другом ЯП
(3) замену неэквивалентного типа данных
ПИК=(T,I,F,R,S), где I - это:
(1) реализация, скрытая часть - программный код
(2) тип компонента
(3) множество интерфейсов компонента
К подхарактеристикам надежности ПО относятся:
(1) безотказность
(2) устойчивость к ошибкам
(3) функциональная полнота
(4) восстанавливаемость
(5) легкость изучения
Диаграмма Ганта - это:
(1) иерархическая структура декомпозиции задач проекта на подзадачи, с расположением на нижнем уровне работ, детализированных на элементы деятельности
(2) линейная диаграмма, на которой задачи проекта представляются сроками в виде отрезков времени, включают даты начала и окончания выполнения задач с учетом возможных задержек или других временных параметров
(3) последовательность вех, определенных менеджером
Persistence-Capable - это:
(1) шаблон для создания класса, его исключений и выдачи сообщений об ошибках, которые могут обнаружиться в программе
(2) шаблон, позволяющий отобразить реляционную схему и использовать ее для создания БД без подключения к MySQL
(3) шаблон, который помогает создать новый JAVA интерфейс и использовать его любым классом через ключевое слово implements
Тестирование эффективности ПО позволяет проверить:
(1) производительность
(2) максимально допустимую нагрузку
(3) максимальный объем данных
(4) взаимосвязи с другими системами и средой
Методы сбора требований включают в себя:
(1) наблюдение за работой действующей системы для отделения проблемных свойств, которые обусловлены кадровыми ресурсами
(2) примеры возможных вариантов выполнения функций, ролей ответственных лиц, запускающих эти варианты или взаимодействующих с системой при ее развертывании и функционировании
(3) интервью с представителями интересов заказчика системы
Связи объектов устанавливаются между:
(1) объектами одного или другого класса
(2) атрибутами одного или другого класса
(3) классами
Шаблон (паттерн) - это:
(1) высокоуровневая абстракция проекта ПС, в которой функции компонентов отделены от задач управления ими
(2) проектные решения по композиции компонентов, источник формирования файла развертывания ПС в среде функционирования
(3) абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственности
Метод Маккарти основан:
(1) на аксиоматическом описании семантики языка программирования исходных программ
(2) на структурной проверке функций, работающих над структурными типами данных, структур данных и диаграмм перехода во время символьного выполнения программ
(3) на определении условий для входных и выходных данных и в выборе контрольных точек в доказываемой программе так, чтобы путь прохождения по программе пересекал хотя бы одну контрольную точку
Динамическое тестирование включает в себя следующие методы:
(1) систематические
(2) статистические
(3) имитационные
(4) математические
Интерфейс между Perl и другими ЯП осуществляется с помощью:
(1) платформенно-ориентированных функций
(2) функций в JNI
(3) интерфейсных функций в С++
Внешняя часть компонента - это:
(1) интерфейс, который определяет взаимодействие компонента с внешней средой и с платформой, на которой он будет выполняться
(2) сервис для взаимодействия со средой или набор правил развертывания
(3) программный фрагмент кода, системная или абстрактная структура, представленные в виде каркаса компонента, спецификации и выходного кода
Внутренние метрики продукта включают:
(1) метрики размера
(2) метрики надежности
(3) метрики сложности
(4) метрики стиля
(5) метрики стоимости
Структура ведения проекта, описанная Вейнбергом, предполагает:
(1) выделение в группе явных лидеров
(2) обезличивание программистов
(3) четкое разделение функций и обязанностей в выполнении задач
(4) одинаковую ответственность в группе за качество продукта
Stub class - это:
(1) шаблон интеграции компонентов в системе CORBA, для вызова метода, который будет выполнен сервером
(2) шаблон интеграции компонентов в системе CORBA, обеспечивает конвертирование данных метода, инициирующего работу клиента в Wire формате, используемом при связывании на стороне клиента сети
(3) шаблон интеграции компонентов в системе CORBA, управляет методами передачи данных и вызовами методов между процессами
Чем считается сопровождение в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764?
(1) модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта
(2) модификацией программного продукта в процессе эксплуатации без сохранения целостности продукта
(3) модификацией программного продукта до процесса эксплуатации
Что дает согласованная область действий по проекту?
(1) возможность заранее определить возможные риски
(2) возможность автоматизировать процесс разработки проекта
(3) возможность оценить требуемые инвестиции в проект
В методе OOAS Шлеера и Меллора предусмотрены следующие нотации для представления динамических аспектов поведения объектов:
(1) диаграмма перехода состояний
(2) график перехода состояний
(3) таблица перехода в состояния
Фильтр композиции служит для:
(1) обновления аспектов без изменения функциональных возможностей
(2) обновления аспектов с изменением функциональных возможностей
(3) обновления аспектов с частичным изменением функциональных возможностей
Валидация требований включает следующие шаги:
(1) создание исполняемой модели требований
(2) проверка правильности спецификации объектов ОМ и параметров интерфейсов
(3) применение валидационных сценариев к модели требований
(4) оценивание результатов поведения модели требований
Функциональные тесты создаются по:
(1) внешним спецификациям функций
(2) проектной информации
(3) результатам работы функций
(4) тексту на ЯП
Независимые от ЯП типы данных стандарта ISO/IEC 11404-1996 не включают:
(1) составные типы данных
(2) сгенерированные типы данных
(3) примитивные типы данных
Реализация - это:
(1) код, который будет использоваться при обращении к операциям, определенных в интерфейсах компонента
(2) физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые операции и инструкции для создания, настройки и функционирования компонента
(3) абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность
Наработка на отказ как атрибут надежности определяет:
(1) защищенность программы
(2) среднее время между появлением угроз
(3) оптимальное время работы системы
Риски могут быть:
(1) "известные", которые можно планировать
(2) "неизвестные", которые не идентифицированы и не могут быть спрогнозированы
(3) "независимые", которые возникают по независимым причинам
Server class - это:
(1) шаблон интеграции компонентов в системе CORBA, содержит деловую логику сервера, экземпляр этого класса сервент регистрируется в ORB и может использоваться клиентом для запуска другого процесса
(2) шаблон интеграции компонентов в системе CORBA, создает сервент и ссылку IOR, которую он записывает в стандартный выходной файл
(3) шаблон интеграции компонентов в системе CORBA, конвертирует инициирующий метод с Wire форматом в формат, который может прочитать экземпляр сервента
Сборка ПО - это:
(1) набор элементов ПО, зафиксированный на этапах жизненного цикла ПО
(2) объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу
(3) коллекция объектов ПО и документации, предназначенная для облегчения процесса разработки, использования и сопровождения ПО
Основные задачи управления требованиями - это:
(1) управление вариантами требований
(2) управление рисками, возникающими при неточном определении требований
(3) валидация требований
(4) реализация требований на этапах ЖЦ
(5) контроль статуса требований
Модель процессов отражает:
(1) совокупность характеристик и связей между объектами предметной области
(2) изменения в моделях состояний
(3) жизненный цикл поведения объектов
Технология разработки прикладной системы с использованием АОП не включает следующие общие этапы:
(1) компиляция, совместная отладка модулей и аспектов, после чего композиция их в готовый программный продукт
(2) физическое размещение аспектов в репозитариях с обеспечением доступа к ним в процессе интеграции
(3) определение точек встраивания аспектов в компоненты и формирование ссылок и связей с другими элементами
(4) изменение системы в процессе ее сопровождения путем добавления новых функциональных возможностей, интерфейсов и операций
Метод простого структурного анализа ориентирован на:
(1) значения предикатов в операторах реализации логических условий, по которым проходили пути выполнения программы
(2) анализ графовой структуры программы, в которой каждая вершина - оператор, а дуга - передача управления между операторами
(3) значения переменных, полученных из выражений формул над входными потоками данных
Объекты тестирования не включают в себя:
(1) компоненты
(2) группы компонентов
(3) система
(4) группы систем
Внешнее преобразование типов данных обладает следующими свойствами:
(1) для каждого примитивного типа для сгенерированного внешнего типа данных преобразование связывается с одним LI-типом данных
(2) для каждого LI-типа данных (примитивного или сгенерированного) преобразование определяет наличие этого типа данных в ЯП
(3) для каждого значения LI-типа данных, участвующего в преобразовании, определяется существование значения любого внутреннего типа данных, преобразуемого в LI-тип данных с взятием этого значения
Задание поискового образа ПИК на основе информационной его модели обеспечивает:
(1) систему хранения ПИК
(2) систему хранения, поиска и сопоставления ПИК
(3) систему поиска и сопоставления ПИК
Инженерия качества - это:
(1) набор методов и мероприятий, с помощью которых программные продукты проверяются на выполнение требований к качеству и снабжаются характеристиками, предусмотренными в требованиях на ПО
(2) набор организационных структур, методик, мероприятий, процессов и ресурсов для осуществления управления качеством
(3) оценка стандартов и процедур, которые выполняются при разработке программ
Версия или конфигурация системы состоит из:
(1) базиса конфигурации
(2) элементов конфигурации
(3) программных компонентов, выполняющих задачи в сформированной версии системы
(4) аналитической модели конфигурации
Интерфейс DII (интерфейс динамического вызова объекта) - это:
(1) интерфейс клиента, содержащий описание внешне видимых параметров и операций объекта в IDL-языке; обеспечивает взаимосвязь клиента с ORB
(2) интерфейс клиента, определяемый во время выполнения программы клиента, используя описание интерфейса из репозитария интерфейсов; обеспечивает доступ (извлечение) к объектам и их интерфейсам во время выполнения
(3) интерфейс клиента, содержащий набор сервисных функций, которые клиент запрашивает у сервера через брокера
Сетевые диаграммы, при помощи которых отображаются результаты планирования:
(1) CРM (Сritical Path Method)
(2) PERT (Program Evaluation and Review Technique)
(3) MPA (Management Process Activities)
Спецификация требований к ПО - это:
(1) формализованное описание функциональных, нефункциональных и системных требований, требований к характеристикам качества, а также к структуре ПО, принципам взаимодействия с другими компонентами, алгоритмам и структуре данных системы
(2) проверка требований, для того чтобы убедиться, что они определяют именно данную систему
(3) процесс проверки правильности спецификации требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам
Архитектура системы - это:
(1) структурная схема интерфейсов системы, взаимодействующих между собой через компоненты
(2) структурная схема компонентов системы, не взаимодействующих между собой
(3) структурная схема компонентов системы, взаимодействующих между собой через интерфейсы
В рамках инженерии ПрО используются следующие типы компонентов в терминологии системы CORBA:
(1) горизонтальные
(2) вертикальные
(3) диагональные
Для доказательства правильности спецификации сообщения создается набор утверждений, доказывающий, что:
(1) для любой пары элементов сообщения, например, A и B, переход от A к B проходит не менее чем за три шага
(2) для любой пары элементов сообщения, например, A и B, переход от A к B проходит быстрее чем переход от B к A
(3) для любой пары элементов сообщения, например, A и B, переход от A к B проходит за один шаг
Все ошибки, которые возникают в программах, принято подразделять на следующие классы:
(1) ошибки интерфейсов
(2) ошибки объема данных
(3) ошибки сопровождения
(4) логические и функциональные ошибки
(5) компонентные ошибки
XDR-стандарт:
(1) обеспечивает преобразование данных в форматы передающей и принимающей платформ
(2) обеспечивает устранение неоднородности во взаимосвязях компонентов в разных ЯП с помощью формата данных, который учитываются разные платформ и среды
(3) содержит язык описания структур данных произвольной сложности и средства преобразования данных, передаваемых на платформы
ПС, построенная из компонентов и предназначенная для функционирования в распределенной среде, состоит из:
(1) серверной программы
(2) интерфейсного модуля
(3) клиентской программы
ПС следует относить к классу:
(1) невосстанавливаемых систем
(2) самовосстанавливающихся систем
(3) саморазрушающихся систем
Согласно стандарту IEEE Std.610-90 управление конфигурацией включает следующие задачи:
(1) идентификация конфигурации
(2) анализ конфигураций
(3) контроль конфигурации
(4) учет статуса конфигурации
(5) аудит конфигурации
Типы данных подразделяются на:
(1) базовые
(2) конструируемые
(3) ссылочные
(4) служебные
Качественный анализ процесса состоит в:
(1) идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования
(2) установлении количественных характеристик процесса и продуктов
(3) создании инфраструктуры процесса
Трассирование требований включает в себя подразделы:
(1) просмотр требований
(2) анализ требований
(3) приемка требований
(4) управление изменениями
Стандарт ГОСТ 34.601-90, регламентирующий стадии и этапы процесса разработки АС, обеспечивает:
(1) концептуальное проектирование
(2) абстрактное проектирование
(3) техническое проектирование
(4) детальное рабочее проектирование
Основными задачами программного агента являются:
(1) взаимодействие с другими агентами
(2) изменение поведения в зависимости от состояния внешней среды
(3) создание новых агентов
(4) самостоятельная работа и контроль своих действий
К событиям процесса не относятся:
(1) разработка программ
(2) верификация программ
(3) выполнение программ
В соответствии с международным стандартом ANSI/IEEE-729-83 дефект (fault) - это:
(1) следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п.
(2) состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки
(3) отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями
Этапы преобразования данных основаны на использовании следующих методов:
(1) метод для обработки данных в транзитной базе при изменении кодировки данных, приведении соответствия между структурами старой и новой БД, а также кодов справочников и классификаторов
(2) метод, выполняющий перенос данных из старой БД в транзитные файлы, а затем занесение этих файлов в транзитную БД
(3) метод, предназначенный для системного переноса данных из транзитной базы в основную БД без проверки преобразованных данных
Репозитарий в интегрированной среде ПрО включает в себя:
(1) компоненты ПИК
(2) новые аспекты из семейства ПрО
(3) классификацию моделей
(4) сервисы и члены семейства ПС
(5) аспекты взаимодействия, синхронизации компонентов
Дефект в ПС - это:
(1) переход ПС из работающего состояния в нерабочее или когда получаются результаты, которые не соответствуют заданным допустимым значениям
(2) следствие ошибок разработчика на любом из процессов разработки
(3) частота появления отказов или дефектов в ПС при ее тестировании или эксплуатации
Идентификация конфигурации - это:
(1) именование всех элементов системы на основе схемы классификации и кодирования элементов, а также методов представления и ведения версий конфигурации с использованием входящих в нее элементов
(2) проверка и управление изменениями системы при формировании версии и эксплуатации
(3) процесс, обеспечивающий идентификацию элементов конфигурации системы при ее создании для проведения систематического контроля, учета и аудита внесенных изменений, а также для поддержки целостности и работоспособности системы
Какие модели создаются в процессе моделирования?
(1) модели вариантов использования
(2) модель анализа
(3) модель проектирования
(4) модель реализации
(5) модель размещения компонентов
Инструменты инженерии ПО обеспечивают:
(1) создание репозитария формальных спецификаций, верифицированных программных объектов разных типов и видов
(2) автоматизированную поддержку процессов разработки ПО
(3) техники оценки/исследования процессов разработки ПО
Укажите правильную цепочку трансформаций при сценарном подходе:
(1) проблема - объект - сценарий - цель
(2) проблема - сценарий - объект - цель
(3) проблема - цель - сценарий - объект
При концептуальном проектировании определяются:
(1) методы взаимодействия пользователей с системой для обеспечения скорости реакции системы
(2) общесистемные компоненты, устанавливающие интерфейс с универсальными системами компьютеров
(3) объекты системы и их атрибуты
(4) интерфейсы с потенциальными пользователями системы для оказания им помощи при формулировке целей и функций системы
История функционирования транзитивной системы хранит одно из соответствующих состояний:
(1) тупиковое состояние, когда каждая из параллельно выполняющихся частей системы находятся в состоянии ожидания
(2) неопределенное состояние, когда каждая из параллельно выполняющихся частей системы находятся в состоянии ожидания
(3) неопределенное состояние, возникающее при выполнении алгоритма с бесконечными циклами
(4) тупиковое состояние, возникающее при выполнении алгоритма с бесконечными циклами
(5) успешное завершение вычислений в среде транзитивной системы
Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:
(1) V - множество переменных, определенных в исходном коде компонента и связанных со свойствами множества временных свойств, отражающими особенности среды компонента
(2) V - множество переменных с типом
(3) V - множество начальных значений для каждой переменной
Тесты проверяют:
(1) полноту функций
(2) корректность требований
(3) корректность выполнения функций
(4) правильность функционирования системы в заданных условиях
К видам сопровождения относятся:
(1) корректировка
(2) предупредительное сопровождение
(3) адаптация продукта к измененным условиям использования системы после ее передачи в эксплуатацию
(4) инсталляция системы
Технология доменной инженерии включает стандартизированные подпроцессы:
(1) формирование ресурсов
(2) разработка базы ресурсов
(3) сопровождение ресурсов
(4) управление ресурсами
Измерительные модели надежности:
(1) основаны на измерении технических характеристик создаваемой программы: длина, сложность, число циклов и др.
(2) предназначены для измерения надежности программного обеспечения, работающего с заданной внешней средой
(3) основываются на серии тестовых прогонов и проводятся на этапах тестирования ПC
После получения новой версии системы заказчику передаются:
(1) версия
(2) конфигурация
(3) документация
(4) отчеты о выявленных ошибках
(5) инструменты управления версиями для самостоятельного внесения изменений при сопровождении системы
Модель управления рисками - это:
(1) модель, определяющая структуру процессов и руководство ими в течение всего времени жизни проекта
(2) модель, с помощью которой определяется порядок и условия реализации упреждающих решений и мер по выявлению наиболее существенных моментов риска
(3) модель, определяющая цели и задачи процесса разработки производственной архитектуры с параллельным и итерационным выполнением отдельных работ
К характеристикам качества относят:
(1) эффективность
(2) надежность
(3) переносимость
(4) стоимость
(5) функциональность
Отношение между сценариями "использует" означает, что:
(1) некоторый сценарий может быть использован как расширение нескольких других сценариев
(2) функция одного сценария является дополнением к функции другого и используется при наличии нескольких вариантов одного и того же сценария
(3) несколько функций одного сценария являются дополнением к нескольким функциям другого
1-й уровень - системные компоненты - осуществляют:
(1) взаимодействие с периферийными устройствами компьютеров (принтеры, клавиатура, сканеры, манипуляторы и т.п.), используются при построении операционных систем
(2) взаимодействие с универсальными сервисными системами среды работы прикладной системы, типа операционные системы, СУБД, системы баз знаний, системы управления сетями и т.п.
(3) решение различных задач (например, бизнес-задач)
(4) решение конкретных задач отдельных групп потребителей информации из разных предметных областей (офисные системы, системы бухгалтерского учета и др.)
Данные в системе композиций и номинативности рассматриваются на следующих уровнях:
(1) композиционный
(2) номинативный
(3) булевский
(4) абстрактный
(5) дескрипционный
Свойство компонента C включается в абстракцию P только тогда, когда:
(1) оно определено в среде этого компонента
(2) оно проверено в среде этого компонента
(3) оно находится в среде этого компонента
В обязанности инженера-тестировщика входят:
(1) оценка тестов
(2) создание тестовых сценариев
(3) исправление ошибок, выявленных на этапе тестирования
(4) составление плана теста
По сравнению с более радикальными подходами к совершенствованию систем реинженерия имеет следующие преимущества:
(1) снижение риска при повторной разработке ПС
(2) обеспечение высокого качества системы и переосвидетельствование ее размера, сложности и структуры
(3) снижение затрат за счет использования компонентов повторного использования при разработке новой ПС
Множество компонентов и систем образуют семейство продуктов, если:
(1) они не имеют своих индивидуальных свойств
(2) они не имеют общие свойства, а каждый член семейства имеет свои индивидуальные свойства
(3) они имеют общие свойства, а каждый член семейства имеет свои индивидуальные свойства
Марковская модель:
(1) базируется на выявлении отказов и моделируется неоднородным процессом
(2) характеризуется дискретным временем и конечным множеством состояний
(3) используется тогда, когда интенсивность отказов пропорциональна не только текущему числу ошибок, но и времени, прошедшему с момента последнего отказа
Функциональный аудит конфигурации проводится:
(1) для подтверждения соответствия фактических характеристик конфигурации продукта требованиям заказчика
(2) для подтверждения взаимного соответствия документации и фактической конфигурации продукта
(3) для подтверждения информации о текущем статусе идентифицированных объектов конфигурационного управления, предложенных изменениях, а также о выявленных дефектах и отклонениях
Модель проектной группы - это:
(1) набор принципов, обеспечивающих создание версии производственной архитектуры предприятия
(2) модель, определяющая роли, обязанности каждого участника проекта и распределение между ними ответственности
(3) трехуровневая структура, сценарный метод проектирования и разработки приложения
Категория "Организационные процессы" процессов жизненного цикла в стандарте ISO/IEC 12207 включает в себя:
(1) управление риском
(2) управление качеством
(3) организационное обеспечение
(4) внедрение процессов
Модель прецедентов моделируемой цели системы не включает в себя:
(1) используемые технологии и принципы взаимодействия с другими системами
(2) подробное описание предметной области
(3) организационные вопросы управления процессом разработки системы
(4) используемые термины предметной области
Архитектурная схема может быть:
(1) распределенная
(2) сосредоточенная
(3) клиент-серверная
(4) компонент-серверная
Алгебра схем Янова - это:
(1) <{АНС, L(2)}; СИГН>, где АНС - совокупность неструктурных схем, L(2) - совокупность различных булевских функций, СИГН - сигнатура из композиции A*B и операция неструктурного перехода П(u, F), а также операции дизъюнкции, конъюнкции и отрицания
(2) {АСС, L(2), СИГН}, двухосновная алгебра, элементами которой являются множество АСС операторов, представленных структурными блок-схемами, множество L(2) булевых функций в сигнатуре СИГН, в которую входят операции дизъюнкции, конъюнкции и отрицания, принимающие значения из L(2)
(3) {ОП, УС, СИГН}, где ОП и УС - множества операторов суперпозиции, входящих в сигнатуру СИГН, и логических условий, определенных на информационном множестве ИМ, СИГН={СИГНад∪Прогн.}, где СИГНад - сигнатура операций Дейкстры, Прогн. - операция прогнозирования
Международный проект по разработке "целостного автоматизированного набора инструментов для проверки корректности ПС" предполагает, что:
(1) верификация будет охватывать все аспекты создания и проверки правильности ПО
(2) верификация станет главной альтернативой обнаружения ошибок в создаваемых программах
(3) верификация позволит разрабатывать ПС без ошибок
Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 не включает:
(1) основные процессы ЖЦ тестирования ПО
(2) тесты, контрольные примеры, критерии и ограничения, оценки результатов программного продукта
(3) планы тестирования различных объектов, необходимые для проведения тестирования ресурсы
Операции рефакторинга над компонентами удовлетворяют условиям:
(1) написание системной спецификации начинается не с "нуля", а с рассмотрения возможностей старой наследуемой системы
(2) операция ориентирована на индустриальные системы в миллион строк кода с использованием метрических оценок характеристик системы
(3) операция не изменяет функциональность компонента и новый компонент может применяться в ранее построенных компонентных системах
Стоимость композиции компонентов определяется так:
(1) math
(2) math
(3) math
Качество ПО - это:
(1) совокупность свойств, которые обеспечивают универсальность решения разнообразных задач
(2) совокупность свойств, которые обеспечивают его способность удовлетворять потребности заказчика в соответствии с назначением
(3) совокупность затрат на разработку
Планирование - это:
(1) руководство работами команды исполнителей проекта для реализации проекта с использованием методов управления, планирования и контроля работ, управление рисками, эффективной организацией работы и коммуникационными потоками в команде исполнителей
(2) процесс распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта
(3) совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС
Более крупные образования компонентов, используемые на практике - это:
(1) паттерны
(2) каркасы
(3) группы
(4) классы
(5) контейнеры
Главными областями программной инженерии не являются:
(1) конструирование ПО
(2) управление конфигурацией
(3) процесс инженерии ПС
(4) инженерия требований
Определение требований, как правило, проводится:
(1) путем обсуждения взглядов заказчика на систему с будущими ее разработчиками
(2) путем обсуждения системы между будущими ее разработчиками без участия заказчика
(3) путем сбора требований к системе заказчика без участия будущих ее разработчиков
Концепт - это:
(1) значение некоторой абстрактной сущности предметной области
(2) абстрактный образ с поведением, которое обусловлено его характеристиками и взаимоотношениями с другими объектами предметной области
(3) конкретный образ с поведением, которое обусловлено его характеристиками и взаимоотношениями с другими объектами предметной области
Сущность структурного подхода к разработке ПС - это:
(1) генерация семейств приложений из отдельных элементов компонентов, аспектов, сервисов, ПИК, каркасов и т.п.
(2) конструирование программ с алгебраическими преобразованиями и функциями интеллектуальных агентов
(3) декомпозиция (разбиение) системы на автоматизируемые функции, которые в свою очередь делятся на подфункции, на задачи и так далее
Языки спецификации областей включают в себя следующие языки:
(1) язык спецификации доменов
(2) язык арифметических операций
(3) табличные языки
(4) язык описания взаимодействий
Тестирование включает в себя:
(1) обнаружение ошибок в ПО путем исполнения выходного кода ПС на тестовых данных
(2) сбор рабочих характеристик в динамике выполнения в конкретной операционной среде
(3) выявление различных ошибок, дефектов, отказов и изъянов, вызванных нерегулярными и аномальными ситуациями или аварийным прекращением работы ПО
Виды интерфейсов не включают в себя:
(1) алгоритмические
(2) аппаратные
(3) программные
Процесс конструирования новых систем из готовых компонентов включает в себя:
(1) интеграцию ПИК в новую разработку с обеспечением интерфейса с подсистемами и другими компонентами
(2) сопоставление цели новой разработки с возможностями найденных ПИК и принятие решений о целесообразности и месте их применения в системе
(3) построение компонентов, реализующих выявленные функции в виде ПИК
(4) понимание сущности новой системы (домена), определение целей ее создания и предъявляемых к ней требований
Первый уровень представления модели качества:
(1) соответствует определению характеристик (показателей) качества ПО, каждая из которых отражает отдельную точку зрения пользователя на качество
(2) предназначен для измерения качества с помощью метрик, каждая из которых определяется как комбинация метода измерения атрибута и шкалы измерения значений атрибутов
(3) это оценочный элемент метрики, который используется для оценки количественного или качественного значения отдельного атрибута показателя ПО
Ответственность за идейную, функциональную сторону проекта несет:
(1) менеджер проекта
(2) главный программист
(3) системный администратор
Контейнер:
(1) определяет повторяемое решение в проблеме объединения компонентов в сложную структуру
(2) это общая структура, типовая для ряда систем с повторно возникающей ситуацией на уровне модели
(3) это оболочка, внутри которой реализуется функциональность компонента
Процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам - это:
(1) валидация требований
(2) верификация требований
(3) спецификация требований к ПО
Управление требованиями не включает в себя следующие подразделы:
(1) извлечение требований
(2) оценка качества
(3) связь с процессами
(4) спецификация требований
Предметная область - это:
(1) абстракция набора связей, которые имеют место между разными видами объектов предметной области, абстрагированных как концепты
(2) абстракция, которой владеют все абстрагированные концепты сущности
(3) то, что анализируется с целью выделения специфичного множества понятий (сущностей, объектов) и связей между ними
Процесс разработки в среде ООП не включает в себя следующие этапы:
(1) автоматизация ПС
(2) модификация ПС
(3) валидация ПС
Предусловие - это:
(1) предикат, который - истинный после выполнения предусловия, завершения текущих операции в заданных точках при выполнении инвариантных свойств программ
(2) предикат с операцией, к которой обращается программа после получения начального состояния для определения правильности выполнения или фиксации ошибочной ситуации
(3) описание операций проверки правильности программы в разных ее точках
Основные задачи процессов верификации и валидации:
(1) проверить и подтвердить, что конечный программный продукт отвечает назначению
(2) проверить и подтвердить, что конечный программный продукт удовлетворяет требованиям заказчика
(3) проверить и подтвердить, что конечный программный продукт работает без ошибок
Если интерфейс реализуется с помощью класса, то:
(1) он не наследует его операции
(2) он наследует часть его операций
(3) он наследует все его операции
Повторные компоненты могут быть:
(1) прикладными
(2) общесистемными
(3) доменными
Удобство применения - это:
(1) группа свойств ПО, обуславливающая его способность выполнять определенный перечень функций, которые удовлетворяют потребностям в соответствии с назначением
(2) группа свойств, обусловливающая способность ПО сохранять работоспособность и преобразовывать исходные данные в результат за установленный период времени, характер отказов которого является следствием внутренних дефектов и условий его применения
(3) совокупность свойств ПО для предполагаемого круга пользователей и отражающих легкость его освоения и адаптации к изменяющимся условиям эксплуатации, стабильность работы и подготовки данных, понимаемость результатов, удобства внесения изменений в программную документацию и в программы
Возможное время выполнения операций оценивается с помощью следующих оценок:
(1) оптимистической
(2) максимальной
(3) наиболее приближенной
(4) пессимистической
(5) вероятностной
Компоненты, которые управляются событиями:
(1) поддерживают правила бизнеслогики, ориентированы на состояния и могут быть связаны с конкретным клиентским сеансом
(2) используются для связи с БД непосредственно и предоставляют данные в объектной форме
(3) функционируют для получения сообщений, поступающих от системы обмена сообщениями JMS (Java Messaging System), и реагируют на них
Метод проектирования UML предназначен для:
(1) сценарного моделирования проекта в наглядном диаграммном виде
(2) идентификации функций и их уточнения сверху-вниз
(3) формального описания функций и данных программы, с которыми эти функции оперируют
Нефункциональные требования определяют:
(1) внешние условия для выполнения системных функций и ограничений на создаваемый продукт, а также требования к описанию подсистем
(2) пользовательские потребности к условиям и среде выполнения функций
(3) некоторые ограничения к свойствам функций или к системе, важных для пользователей или разработчиков
Связи между объектами могут быть:
(1) связь один ко многим (1:N)
(2) связь ноль к одному (0:1)
(3) связь один к одному (1:1)
(4) связь многие ко многим (M:N)
Диаграмма деятельности задает:
(1) поведение совокупности объектов, функции которых ориентированы на достижение целей системы, а также взаимосвязи тех ролей, которые обеспечивают сотрудничество
(2) взаимодействие объектов с помощью сценариев, отображающих события, связанные с их созданием и уничтожением
(3) поведение системы в виде определенных работ, которые может выполнять система или актер, виды работ могут зависеть от принятия решений в зависимости от заданных условий или ограничений
Количество компонентов произведения d находится следующим образом:
(1) math
(2) math
(3) math
Цель тестирования - это:
(1) проверка работы реализованных функций в соответствии с их спецификацией
(2) проверка выполнения специфических требований для программного продукта
(3) проверка отражения программным продуктом согласованных требований к его реализации
Интероперабельность - это:
(1) способность раздельного, несогласованного взаимодействия разнородных компонентов системы для решения определенной задачи
(2) способность совместного, согласованного взаимодействия определенных компонентов системы для решения разнородных задач
(3) способность совместного, согласованного взаимодействия разнородных компонентов системы для решения определенной задачи
К компонентам общего назначения не относятся:
(1) трансляторы
(2) электронная почта
(3) системы генерации
(4) ОС
Переносимость - это:
(1) группа свойств, определяющая усилия, необходимые для выполнения, приспособленность к диагностике отказов и последствий внесения изменений, модификации и аттестации модифицируемого ПО
(2) группа свойств, характеризующаяся степенью соответствия используемых ресурсов среды функционирования уровню качества (надежности) функционирования ПО при заданных условиях применения
(3) группа свойств ПО, обеспечивающая его приспособленность для переноса из одной среды функционирования в другие, усилия для переноса и адаптацию ПО к новой среде функционирования
Анализ проекта состоит в:
(1) формировании команды разработчиков из хороших специалистов
(2) анализе проектирования элементов системы и критике результатов труда исполнителей, а не режима работы
(3) изучении своих ошибок при реализации предыдущего проекта, чтобы не повторить их в новом проекте
CustomTask - это:
(1) шаблон развертывания компонентов, создающий проект, который не содержит в себе ни одного класса или пакета классов, разрешающий подключать новые классы и пакеты в схему проекта
(2) шаблон развертывания компонентов, разрешающий сконфигурировать общую схему проекта с помощью иерархии системы файлов как корневой узел схемы нового проекта. Затем в проект добавляются новые компоненты, они пакетируются и делается их детальный просмотр
(3) шаблон развертывания компонентов, позволяющий создать новый проект, начиная с формирования первоначального класса в этом проекте
В область знаний "Конструирование ПО" не входят разделы:
(1) снижение сложности
(2) выявление требований
(3) структуризация проверок
(4) структура и архитектура ПО
Системные требования определяют:
(1) перечень функций или сервисов, которые должна выполнять система, а также ограничений на данные и поведение системы
(2) цели и задачи, которые пользователям позволит решать будущая система
(3) внешние условия для выполнения системных функций и ограничений на создаваемый продукт, а также требования к описанию подсистем
Информационная модель - это:
(1) совокупность объектов предметной области
(2) совокупность характеристик и связей между объектами предметной области
(3) совокупность объектов предметной области, их характеристик и связей между ними, созданная по принципу реляционной модели данных
Диаграмма реализации состоит из:
(1) диаграммы компонента и размещения
(2) диаграммы состояний и деятельности
(3) диаграммы компонента и сотрудничества
(4) диаграммы состояний и размещения
Концептор - это:
(1) декларативное описание объектов и императивное описание операторов вычисления выражений тела
(2) конструктор построения термов из выражений и формул
(3) конструктор, преобразующий термы в термы
Статический анализ заключается в:
(1) проверке прохождения всех путей программ
(2) инспекции исходного кода и сквозного контроля программы
(3) накапливании информации об ошибках
(4) проверке корректности ПС на множестве тестов
Системы math и math для языков math и math - изоморфны, если их типы данных q, t:
(1) определены на одном том же множестве простых или сложных типов данных
(2) определены на разных множествах простых или сложных типов данных
(3) не определены
ПИК=(T,I,F,R,S), где R - это:
(1) реализация, скрытая часть - программный код
(2) тип компонента
(3) множество интерфейсов компонента
Достижение надежности ПО обеспечивается:
(1) предотвращением отказа
(2) устранением отказа
(3) повышением квалификации сотрудников
(4) приобретением более совершенного оборудования
(5) оценкой возможности появления новых отказов и мер борьбы с ними
Состав и количество сотрудников, входящих в команду проекта, зависит от:
(1) масштаба работ
(2) наличия помещения
(3) опыта сотрудников
Interface - это:
(1) шаблон для создания класса, его исключений и выдачи сообщений об ошибках, которые могут обнаружиться в программе
(2) шаблон, позволяющий отобразить реляционную схему и использовать ее для создания БД без подключения к MySQL
(3) шаблон, который помогает создать новый JAVA интерфейс и использовать его любым классом через ключевое слово implements
Тестирование эффективности ПО не позволяет проверить:
(1) производительность
(2) максимально допустимую нагрузку
(3) максимальный объем данных
(4) работу системы на различных конфигурациях аппаратуры
Результаты обследования и анализа предметной области фиксируются в:
(1) договоре между заказчиком и исполнителем проекта
(2) документе описания предметной области
(3) документе описания требований
Модель состояний отображает:
(1) совокупность объектов предметной области, их характеристик и связей между ними
(2) динамическое поведение и изменение состояний каждого из объектов информационной модели
(3) жизненный цикл поведения объектов
Каркас - это:
(1) высокоуровневая абстракция проекта ПС, в которой функции компонентов отделены от задач управления ими
(2) проектные решения по композиции компонентов, источник формирования файла развертывания ПС в среде функционирования
(3) абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственности
Метод Дейкстры основан:
(1) на модели вычислений, оперирующей с историями результатов вычислений программы, анализом путей прохождения и правил обработки большого объема информации
(2) на формальном исследовании текста программы с помощью предикатов первого порядка
(3) на аксиоматическом описании семантики языка программирования исходных программ
Систематические методы тестирования делятся на следующие методы:
(1) метод "черного ящика"
(2) метод "серого ящика"
(3) метод "белого ящика"
Интерфейс между Matlab и другими ЯП осуществляется с помощью:
(1) интерфейса между Visual Basic
(2) функций из Matlab
(3) вызова приложения из среды
Внутренняя часть компонента включает в себя:
(1) интерфейс
(2) реализацию
(3) схему разработки
Метрики использования позволяют оценить:
(1) свойства программы
(2) результаты эксплуатации программы
(3) сложность внедрения программы
Что не входит в понятие главных факторов осуществления задач программного проекта?
(1) объем работ, имеющиеся ресурсы и ограничения
(2) стоимость выполнения задач и необходимых ресурсов
(3) компетентность специалистов
(4) психологический климат в группе
ORB class - это:
(1) шаблон интеграции компонентов в системе CORBA, для вызова метода, который будет выполнен сервером
(2) шаблон интеграции компонентов в системе CORBA, обеспечивает конвертирование данных метода, инициирующего работу клиента в Wire формате, используемом при связывании на стороне клиента сети
(3) шаблон интеграции компонентов в системе CORBA, управляет методами передачи данных и вызовами методов между процессами
Реорганизация кода для улучшения характеристик и показателей качества объектно-ориентированных и компонентных программ без изменения их поведения - это:
(1) реинженерия
(2) рефакторинг
(3) реверсная инженерия
Анализ требований не включает в себя подразделы:
(1) описание документа
(2) согласование документа
(3) техника обсуждения
В таблице перехода в состояния:
(1) каждое состояние представляется строкой, а каждое событие, воздействующее на объект - столбцом
(2) каждое состояние представляется столбцом, а каждое событие, воздействующее на объект - строкой
(3) каждое состояние представляется строками и столбцами, а каждое событие, воздействующее на объект - клетками таблицы перехода
С точки зрения моделирования аспекты можно рассматривать как:
(1) аспекты декомпозиции системы, в которых отдельные каркасы пересекают ряд многократно используемых ПИК
(2) каркасы декомпозиции системы, в которых отдельные аспекты пересекают ряд многократно используемых ПИК
(3) фрагменты отладочных программ для выдачи промежуточных результатов
Валидация требований не включает следующие шаги:
(1) формализованное описание требований в виде сценариев
(2) создание специальных сценариев для валидации требований
(3) определение альтернативных событий, заданных на языке диаграмм UML
(4) анализ непредвиденных событий
В задачи функционального тестирования не входят:
(1) идентификация внешних функций
(2) корректное описание модели функционирования ПО в среде эксплуатации у заказчика
(3) идентификация множества входных данных каждой функции
(4) оформление требований и ограничений к качеству ПО
Типы данных в стандарте описываются в:
(1) ЯП низкого уровня
(2) LI-языке
(3) абстрактном ЯП
Паттерн - это:
(1) код, который будет использоваться при обращении к операциям, определенных в интерфейсах компонента
(2) физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые операции и инструкции для создания, настройки и функционирования компонента
(3) абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность
Количественными называются показатели качества, которые определяются с помощью:
(1) метрических шкал
(2) порядковых шкал
(3) классификационных шкал
Планирование управления рисками - это:
(1) процесс принятия решений по применению и планированию управления рисками для конкретного проекта
(2) процесс качественного анализа идентификации рисков и оценка риска, требующего быстрого реагирования
(3) разработка методов и технологий снижения отрицательного воздействия рисков на проект
Skeleton class - это:
(1) шаблон интеграции компонентов в системе CORBA, содержит деловую логику сервера, экземпляр этого класса сервент регистрируется в ORB и может использоваться клиентом для запуска другого процесса
(2) шаблон интеграции компонентов в системе CORBA, создает сервент и ссылку IOR, которую он записывает в стандартный выходной файл
(3) шаблон интеграции компонентов в системе CORBA, конвертирует инициирующий метод с Wire форматом в формат, который может прочитать экземпляр сервента
Аудит конфигурации ПО - это:
(1) работы по координации, утверждению или отбрасыванию реализованных изменений в элементах конфигурации продукта
(2) документирование функциональных и физических характеристик элементов конфигурации ПО
(3) деятельность, которая выполняется для оценки продукта и процессов на соответствие стандартам, инструкциям, планам и процедурам
Управление рисками, возникающими при неточном определении требований, состоит:
(1) в оценке их влияния на другие процессы
(2) в предупреждении рисковых ситуаций
(3) в контроле появления и обнаружения неадекватных ситуаций при реализации требований
(4) в формировании конфигурации системы в принятых для системы терминах и обозначениях
Последовательность выполняемых процессов образует:
(1) поток управления
(2) поток состояний
(3) поток данных
Активные библиотеки содержат:
(1) базовый код реализации понятий ПрО
(2) функции компиляторов, средства оптимизации, редактирования, отображения
(3) целевой код обеспечения оптимизации, адаптации, визуализации и редактирования
Метод символьной проверки применяется при:
(1) анализе графовой структуры программы, в которой каждая вершина - оператор, а дуга - передача управления между операторами
(2) анализе логики программы и выявлении операторов, по которым не проходит путь вычислений
(3) обнаружении противоречий в описании логики программы
Какой метод тестирования, при котором можно использовать структуру объекта для организации тестирования по различным ветвям, является предпочтительным?
(1) метод "черного ящика"
(2) метод "серого ящика"
(3) метод "белого ящика"
Внутреннее преобразование типов данных обладает следующими свойствами:
(1) для каждого LI-типа данных преобразование определяет отношение между допустимым значением этого типа и эквивалентным значением соответствующего внутреннего типа ЯП
(2) для каждого значения внутреннего типа данных преобразование определяет, является ли это значение образом (после преобразования) какого-то значения LI-типа данных и его способ преобразования
(3) для каждого внутреннего типа данных преобразование определяет связь между допустимым значением внутреннего типа данных и эквивалентным значением соответствующего LI-типа данных
Поисковый образ упрощает поиск и сокращает сроки разработки ПС за счет:
(1) отображения базовых функций и понятий компонента
(2) открытия представления данных
(3) обработки исключительных ситуаций, возникающих в процессе выполнения
Планирование качества представляет собою:
(1) деятельность, направленную на определение целей и требований к качеству
(2) методы и виды деятельности оперативного характера для текущего управления процессом проектирования и устранения причин плохого или неудовлетворительного функционирования ПС
(3) выполнение и проверку того, что объект разработки выполняет указанные требования к качеству
Количественная оценка рисков - это:
(1) процесс принятия решений по применению и планированию управления рисками для конкретного проекта
(2) процесс определения вероятности возникновения рисков, влияния последствий рисков на проект и принятия решений по оценке риска
(3) разработка методов и технологий снижения отрицательного воздействия рисков на проект
Интерфейс сервисов ORB - это:
(1) интерфейс клиента, содержащий описание внешне видимых параметров и операций объекта в IDL-языке; обеспечивает взаимосвязь клиента с ORB
(2) интерфейс клиента, определяемый во время выполнения программы клиента, используя описание интерфейса из репозитария интерфейсов; обеспечивает доступ (извлечение) к объектам и их интерфейсам во время выполнения
(3) интерфейс клиента, содержащий набор сервисных функций, которые клиент запрашивает у сервера через брокера
Область знаний "Управление инженерией ПО" не включает в себя разделы:
(1) организационное управление
(2) концепции процесса инженерии ПО
(3) управление процессом и проектом
(4) количественный анализ процесса
Фиксация требований не включает в себя подразделы:
(1) спецификация требований
(2) сбор требований
(3) согласование документа
(4) трассирование требований
(5) систематизация требований
Условия построения архитектуры системы включают в себя:
(1) декомпозиция системы на компоненты или модули
(2) иерархическое представление абстракции системы и скрытие тех деталей, которые будут отработаны на следующих уровнях
(3) определение всех функций системы
(4) определение входных и выходных данных
При определении общих и изменяемых характеристик представителей семейства систем используются:
(1) пространство решений
(2) пространство процессов
(3) пространство проблемы
Контекст - это:
(1) описание типов, переменных и каналов
(2) описание переходов, состояний, набора операций процесса и перехода на следующее состояние
(3) описание условий выполнения и диаграмм процессов
Ошибки ввода-вывода и манипулирования данными являются следствием:
(1) неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов
(2) некачественной подготовки данных для выполнения программы, сбоев при занесении их в базы данных или при выборке из нее
(3) неправильно определенных функций, нарушения порядка их применения или отсутствия полноты их реализации
(4) того, что реализованные методы доступа и размеры баз данных не удовлетворяют реальным объемам информации системы или интенсивности их обработки
XML-стандарт:
(1) обеспечивает преобразование данных в форматы передающей и принимающей платформ
(2) обеспечивает устранение неоднородности во взаимосвязях компонентов в разных ЯП с помощью формата данных, который учитываются разные платформ и среды
(3) содержит язык описания структур данных произвольной сложности и средства преобразования данных, передаваемых на платформы
В функции интерфейсного модуля клиента входят:
(1) подготовка внешних данных клиента (параметров)
(2) ожидание сообщений клиента и их обработка
(3) запуск удаленной процедуры и передача ей параметров клиента
(4) обработка разных ошибок, возврат данных от сервера к клиенту
К факторам гарантии надежности относятся:
(1) риск как совокупность угроз, приводящих к неблагоприятным последствиям и ущербу системы или среды
(2) угроза как проявление неустойчивости, нарушающей безопасность системы
(3) анализ риска - изучение угрозы или риска, их частота и последствия
(4) целостность - способность системы сохранять устойчивость работы и не иметь риска
Результатом управления конфигурацией является:
(1) отчет о проведенных изменениях версии системы и документации
(2) документ о передаче измененной версии пользователю
(3) репозитарий базовых библиотек и ресурсов
Сервлет - это:
(1) спецификация точек доступа к компоненту
(2) небольшая программа, которая выполняется на серверной стороне WEB, расширяет функциональные возможности WEB-сервера, облегчает доступ к ресурсам и разрешает процессу читать данные из HTTP, запрашивать WEB-сервер и записывать данные из сервера ответ в HTTP
(3) окно со строкой заголовка, которое может быть встроено в апплет или существовать само по себе в программе
Основными целями процесса являются:
(1) автоматизация процессов
(2) улучшение различных аспектов программной инженерии
(3) создание новых версий ПО
Трассировка обеспечивает:
(1) ведение базы данных объектов трассировки и отношений между ними
(2) автоматическое формирование требований к системе
(3) ввод более сложных отношений вместо простых связей или специфических отношений
Детальное рабочее проектирование - это:
(1) отображение требований определение задач и принципов их реализации в среде функционирования системы
(2) определение главных структурных особенностей создаваемой системы
(3) спецификация алгоритмов задач, построении БД и программного обеспечения системы
(4) построение концептуальной модели, уточнении и согласовании требований
Координация агентов - это:
(1) процесс обеспечения действий агентов без внешнего управляющего воздействия
(2) процесс обеспечения последовательного функционирования при согласованности их поведения и без взаимных конфликтов
(3) процесс обеспечения изменения поведения в зависимости от состояния внешней среды
Схема спецификации процесса - это:
(1) описание типов, переменных и каналов
(2) описание переходов, состояний, набора операций процесса и перехода на следующее состояние
(3) описание условий выполнения и диаграмм процессов
Типы отказов не включают в себя:
(1) аппаратный
(2) информационный
(3) программный
(4) системный
Проблема преобразования и переноса данных между различными СУБД решается на основе использования:
(1) транзитных файлов, в которые копируются данные из старой БД для переноса в новую БД
(2) специального формата данных, в который конвертируются все переносимые данные из старой БД
(3) специального драйвера (две СУБД соединяются друг с другом и напрямую передают данные, используя интерфейс)
Репозитарий в интегрированной среде ПрО не включает в себя:
(1) компоненты ПИК
(2) новые аспекты из семейства ПрО
(3) определение области действий объектов ПрО
(4) аспекты безопасности, защиты, изменения ПИК
Интенсивность отказов - это:
(1) переход ПС из работающего состояния в нерабочее или когда получаются результаты, которые не соответствуют заданным допустимым значениям
(2) следствие ошибок разработчика на любом из процессов разработки
(3) частота появления отказов или дефектов в ПС при ее тестировании или эксплуатации
Контроль конфигурации - это:
(1) именование всех элементов системы на основе схемы классификации и кодирования элементов, а также методов представления и ведения версий конфигурации с использованием входящих в нее элементов
(2) проверка и управление изменениями системы при формировании версии и эксплуатации
(3) процесс, обеспечивающий идентификацию элементов конфигурации системы при ее создании для проведения систематического контроля, учета и аудита внесенных изменений, а также для поддержки целостности и работоспособности системы
Модель анализа - это:
(1) модель, отражающая взаимодействие между пользователями и ПС
(2) модель, обеспечивающая спецификацию требований к системе и описание вариантов использования как кооперации между концептуальными классификаторами
(3) модель, обеспечивающая создание статической структуры и интерфейсов системы, а также реализацию вариантов использования в виде набора коопераций между подсистемами, классами и интерфейсами
К инструментам конструирования ПО относятся:
(1) интерпретаторы
(2) инструменты реинжинерии
(3) компиляторы и генераторы кода
(4) интегрированные среды разработки
Укажите корректные правила для специальной графической нотации в модели сценариев:
(1) сценарий изображается овалом, в середине которого указывается название иконы
(2) актор изображается овалом, в середине которого указывается название иконы
(3) сценарий изображается стрелкой, над которой указывается название иконы
(4) актор обозначается иконой человека, под которой указывается название
Техническое проектирование - это:
(1) отображение требований определение задач и принципов их реализации в среде функционирования системы
(2) определение главных структурных особенностей создаваемой системы
(3) спецификация алгоритмов задач, построении БД и программного обеспечения системы
(4) построение концептуальной модели, уточнении и согласовании требований
Транзитивные системы называют бисимуляционно эквивалентными, если:
(1) каждое состояние эквивалентно другой системе
(2) каждое состояние эквивалентно состоянию другой системы
(3) каждое состояние неэквивалентно состоянию другой системы
Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:
(1) P - множество временных свойств, отражающее особенности среды компонента
(2) P - множество состояний, каждое из которых связано с ассоциативным действием
(3) P - операции связи для взаимодействия с другими компонентами
Тесты не проверяют:
(1) согласованность интерфейсов
(2) корректность генерации входных данных
(3) надежность выполнения системы
Внесение изменений в ПО можно рассматривать как:
(1) признак его устаревания
(2) важный недостаток системы
(3) эволюционный путь его развития
Основное требование к инженерии ПрО - это:
(1) обеспечение многоразового применения используемых решений для семейства ПС
(2) производство (линейка) одиночной системы из ПИК по требованиям к ней
(3) создание архитектурного базиса из множества ПИК
Оценочные модели надежности:
(1) основаны на измерении технических характеристик создаваемой программы: длина, сложность, число циклов и др.
(2) предназначены для измерения надежности программного обеспечения, работающего с заданной внешней средой
(3) основываются на серии тестовых прогонов и проводятся на этапах тестирования ПC
Построение адекватной схемы классификации и идентификации объектов конфигурационного управления выполняется одновременно со структуризацией продукта и заключается в определении:
(1) конфигурации продукта и ее версий
(2) контролируемых единиц конфигурации и их версий
(3) всех составляющих конфигурационного базиса и их редакций
(4) соотношения между количеством выполняемых задач и количеством пунктов конфигурации
Модель процесса проектирования - это:
(1) модель, определяющая структуру процессов и руководство ими в течение всего времени жизни проекта
(2) модель, с помощью которой определяется порядок и условия реализации упреждающих решений и мер по выявлению наиболее существенных моментов риска
(3) модель, определяющая цели и задачи процесса разработки производственной архитектуры с параллельным и итерационным выполнением отдельных работ
Деятельности и техники гарантии качества включают:
(1) проектирование ПО
(2) инспекцию ПО
(3) разработку ПО
(4) валидацию ПО
Описание сценария включает в себя:
(1) список акторов, которые будут запускать сценарии модели
(2) краткое содержание сценария в неформальном представлении
(3) описание классов системы
(4) функции, которые реализуются при выполнении сценария
4-й уровень - прикладные программные системы - осуществляют:
(1) взаимодействие с периферийными устройствами компьютеров (принтеры, клавиатура, сканеры, манипуляторы и т.п.), используются при построении операционных систем
(2) взаимодействие с универсальными сервисными системами среды работы прикладной системы, типа операционные системы, СУБД, системы баз знаний, системы управления сетями и т.п.
(3) решение различных задач (например, бизнес-задач)
(4) решение конкретных задач отдельных групп потребителей информации из разных предметных областей (офисные системы, системы бухгалтерского учета и др.)
Принципами ЭП не являются:
(1) принцип абстрактности
(2) принцип прагматичности
(3) принцип композиционности
(4) принцип дескриптивности
Модель ОКМ - это:
(1) вычислительная модель системы, заданная на конечном множестве взаимодействующих процессов
(2) совокупность проверенных компонентов, спецификаций их временных свойств и условий функционирования, которые проверяются с помощью аппарата асинхронной передачи сообщений
(3) совокупность специфицированных компонентов и их временных свойств для обеспечения верификации
В обязанности инженера-тестировщика не входят:
(1) оценка тестов
(2) создание тестовых сценариев
(3) исправление ошибок, выявленных на этапе тестирования
(4) составление плана теста
Причины, требующие преобразования исходного кода программ в другой язык, могут быть:
(1) обновление платформы аппаратных средств, на которой может не выполняться компилятор ЯП
(2) изменение структуры программы в связи с переходом на новый стандартный язык программирования
(3) необходимость изменения отдельного компонента системы для придания ему новых функциональных и структурных характеристик, удовлетворяющих требованиям конфигурации
(4) недостаток квалифицированного персонала для программ, написанных в ЯП, вышедших из употребления
К альтернативным свойствам ПИК относятся:
(1) свойства, которые отображают особенности выбора представителя семейства как многократно используемого
(2) свойства, которые отражают некоторые специфические особенности или могут отсутствовать
(3) свойства, которые обязательно присутствуют в каждом из представителей семейства систем, а их реализация может иметь некоторые отличия
Пуассоновская модель:
(1) базируется на выявлении отказов и моделируется неоднородным процессом
(2) характеризуется дискретным временем и конечным множеством состояний
(3) используется тогда, когда интенсивность отказов пропорциональна не только текущему числу ошибок, но и времени, прошедшему с момента последнего отказа
Физический аудит конфигурации проводится:
(1) для подтверждения соответствия фактических характеристик конфигурации продукта требованиям заказчика
(2) для подтверждения взаимного соответствия документации и фактической конфигурации продукта
(3) для подтверждения информации о текущем статусе идентифицированных объектов конфигурационного управления, предложенных изменениях, а также о выявленных дефектах и отклонениях
Модель приложения - это:
(1) набор принципов, обеспечивающих создание версии производственной архитектуры предприятия
(2) модель, определяющая роли, обязанности каждого участника проекта и распределение между ними ответственности
(3) трехуровневая структура, сценарный метод проектирования и разработки приложения
Жизненный цикл программной системы - это:
(1) тексты требований к разработке программной системы и согласованные с заказчиком договоренности
(2) действия предприятия-разработчика программного продукта
(3) определенная последовательность процессов (этапов), начиная от постановки задачи до ее воплощения в готовую программу, эксплуатации и изъятия из эксплуатации
Экземпляр прецедента - это:
(1) последовательность действий, выполняемых системой и наблюдений за получением результата
(2) неформальное описание каждого из входящих в нее диаграмм сценариев
(3) некоторый поток событий в системе, когда прецедент будет выполнен
Что осуществляет абстрактный объект-посредник?
(1) осуществляет трансформацию абстрактного интерфейса в интерфейс конкретного сервиса системы
(2) связывает объекты внутри системы друг с другом
(3) вносит изменения в модель анализа требований и в архитектуру системы
Объекты алгоритмики - это:
(1) модели алгоритмов, представляемые в виде программ
(2) модели программ, представляемые в виде алгоритмов
(3) модели алгоритмов и программ, представляемые в виде схем
Функции репозитария не включают в себя:
(1) разработка механизмов интероперабельности и взаимодействия для переноса готовых верифицированных продуктов из репозитария в новые распределенные и сетевые среды
(2) разработка всевозможных методов верификации
(3) накопление верифицированных спецификаций, методов доказательства, программных объектов и реализаций кодов
(4) разработка стандартных форм для задания и обмена формальными спецификациями разных объектов, инструментов и готовых систем
Расчет продолжительности выполнения функций путем сбора средних показателей скорости выполнения операторов служит для:
(1) формулирования выводов о направлениях дальнейшей проверки правильности программы или их завершении
(2) определения стратегии и путей тестирования
(3) выявления компонентов, которые требуют большого времени выполнения в реальной среде
Операции реверсной инженерии над компонентами удовлетворяют условиям:
(1) написание системной спецификации начинается не с "нуля", а с рассмотрения возможностей старой наследуемой системы
(2) операция ориентирована на индустриальные системы в миллион строк кода с использованием метрических оценок характеристик системы
(3) операция не изменяет функциональность компонента и новый компонент может применяться в ранее построенных компонентных системах
Стоимость поиска и исследования возможностей применения ПИК из репозитария для реализации некоторой определенной функции ПрО вычисляется с помощью выражения:
(1) math
(2) math
(3) math