Ответы на курс: Методы и средства инженерии программного обеспечения
Процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам — это:
|
спецификация требований к ПО |
|
валидация требований |
 |
верификация требований |
Метод проектирования UML предназначен для:
|
сценарного моделирования проекта в наглядном диаграммном виде |
|
идентификации функций и их уточнения сверху-вниз |
|
формального описания функций и данных программы, с которыми эти функции оперируют |
Жизненный цикл программной системы — это:
|
определенная последовательность процессов (этапов), начиная от постановки задачи до ее воплощения в готовую программу, эксплуатации и изъятия из эксплуатации |
|
действия предприятия-разработчика программного продукта |
|
тексты требований к разработке программной системы и согласованные с заказчиком договоренности |
Тестирование ПО — это:
|
процесс проверки готовой программы в статике и в динамике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными |
|
процесс проверки готовой программы только в динамике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными |
|
процесс проверки готовой программы только в статике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными |
Качественный анализ процесса состоит в:
|
установлении количественных характеристик процесса и продуктов |
|
идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования |
|
создании инфраструктуры процесса |
Сборка ПО — это:
|
объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу |
|
коллекция объектов ПО и документации, предназначенная для облегчения процесса разработки, использования и сопровождения ПО |
|
набор элементов ПО, зафиксированный на этапах жизненного цикла ПО |
Модель прецедентов моделируемой цели системы состоит из:
|
основных действующих лиц и их целей |
|
фрагментов диаграммы последовательности и конструкций потока управления |
|
требований к тестированию и к процедуре развертывания системы у заказчика |
|
требований к форматам и протоколам взаимодействия |
Укажите правильную цепочку трансформаций при сценарном подходе:
|
проблема — цель — сценарий — объект |
|
проблема — объект — сценарий — цель |
|
проблема — сценарий — объект — цель |
Определение требований, как правило, проводится:
|
путем обсуждения системы между будущими ее разработчиками без участия заказчика |
|
путем обсуждения взглядов заказчика на систему с будущими ее разработчиками |
|
путем сбора требований к системе заказчика без участия будущих ее разработчиков |
Основные средства UML к формированию и представлению требований к системе и к ПО — это:
|
диаграммы активности |
|
use case сценарии или прецеденты |
|
диаграммы классов |
Методы сбора требований включают в себя:
|
интервью с представителями интересов заказчика системы |
|
наблюдение за работой действующей системы для отделения проблемных свойств, которые обусловлены кадровыми ресурсами |
|
примеры возможных вариантов выполнения функций, ролей ответственных лиц, запускающих эти варианты или взаимодействующих с системой при ее развертывании и функционировании |
Результаты обследования и анализа предметной области фиксируются в:
|
договоре между заказчиком и исполнителем проекта |
|
документе описания требований |
|
документе описания предметной области |
Концепт — это:
|
абстрактный образ с поведением, которое обусловлено его характеристиками и взаимоотношениями с другими объектами предметной области |
|
значение некоторой абстрактной сущности предметной области |
|
конкретный образ с поведением, которое обусловлено его характеристиками и взаимоотношениями с другими объектами предметной области |
Последовательность выполняемых процессов образует:
|
поток состояний |
|
поток управления |
|
поток данных |
Событие — это:
|
положение или ситуация объекта, определяемая правилами и линией поведения |
|
инцидент, который заставляет объект переходить из одного состояния в другое |
|
множество состояний, в которых объект может находиться |
Что осуществляет абстрактный объект-посредник?
|
вносит изменения в модель анализа требований и в архитектуру системы |
|
связывает объекты внутри системы друг с другом |
|
осуществляет трансформацию абстрактного интерфейса в интерфейс конкретного сервиса системы |
Взаимодействие объектов — это:
|
обмен сообщениями между элементами системы |
|
изменение атрибутов одного объекта другим объектом |
|
выполнение одним объектом функций другого объекта |
Сколько этапов анализа предметной области в методе OOAS Шлеера и Меллора?
|
2 |
|
3 |
|
1 |
Детальное рабочее проектирование — это:
|
спецификация алгоритмов задач, построении БД и программного обеспечения системы |
|
отображение требований определение задач и принципов их реализации в среде функционирования системы |
|
построение концептуальной модели, уточнении и согласовании требований |
|
определение главных структурных особенностей создаваемой системы |
Архитектура системы — это:
|
структурная схема компонентов системы, не взаимодействующих между собой |
|
структурная схема интерфейсов системы, взаимодействующих между собой через компоненты |
|
структурная схема компонентов системы, взаимодействующих между собой через интерфейсы |
Модель процессов отражает:
|
жизненный цикл поведения объектов |
|
изменения в моделях состояний |
|
совокупность характеристик и связей между объектами предметной области |
При концептуальном проектировании определяются:
|
объекты системы и их атрибуты |
|
интерфейсы с потенциальными пользователями системы для оказания им помощи при формулировке целей и функций системы |
|
общесистемные компоненты, устанавливающие интерфейс с универсальными системами компьютеров |
|
методы взаимодействия пользователей с системой для обеспечения скорости реакции системы |
В таблице перехода в состояния:
|
каждое состояние представляется строками и столбцами, а каждое событие, воздействующее на объект — клетками таблицы перехода |
|
каждое состояние представляется столбцом, а каждое событие, воздействующее на объект — строкой |
|
каждое состояние представляется строкой, а каждое событие, воздействующее на объект — столбцом |
Связи между объектами могут быть:
|
связь один к одному (1:1) |
|
связь один ко многим (1:N) |
|
связь многие ко многим (M:N) |
|
связь ноль к одному (0:1) |
Алгебра схем Янова — это:
|
{АСС, L(2), СИГН}, двухосновная алгебра, элементами которой являются множество АСС операторов, представленных структурными блок-схемами, множество L(2) булевых функций в сигнатуре СИГН, в которую входят операции дизъюнкции, конъюнкции и отрицания, принимающие значения из L(2) |
|
{ОП, УС, СИГН}, где ОП и УС — множества операторов суперпозиции, входящих в сигнатуру СИГН, и логических условий, определенных на информационном множестве ИМ, СИГН={СИГНад?Прогн.}, где СИГНад — сигнатура операций Дейкстры, Прогн. — операция прогнозирования |
|
<{АНС, L(2)}; СИГН>, где АНС — совокупность неструктурных схем, L(2) — совокупность различных булевских функций, СИГН — сигнатура из композиции A*B и операция неструктурного перехода П(u, F), а также операции дизъюнкции, конъюнкции и отрицания |
UML — это:
|
универсальный многовариантный язык |
|
универсальный многонациональный язык |
|
унифицированный язык моделирования |
Генерирующее программирование — это:
|
генерация семейств приложений из отдельных элементов компонентов, аспектов, сервисов, ПИК, каркасов |
|
парадигма построения гибких к изменению ПС путем добавления новых аспектов (функций), обеспечивающих безопасность и взаимодействие компонентов с другой средой |
|
стратегия разработки, в рамках которой разработчики системы вместо операций и функций мыслят объектами |
Диаграмма деятельности задает:
|
поведение совокупности объектов, функции которых ориентированы на достижение целей системы, а также взаимосвязи тех ролей, которые обеспечивают сотрудничество |
|
взаимодействие объектов с помощью сценариев, отображающих события, связанные с их созданием и уничтожением |
|
поведение системы в виде определенных работ, которые может выполнять система или актер, виды работ могут зависеть от принятия решений в зависимости от заданных условий или ограничений |
Ассоциация — это:
|
зависимость между объектами разных классов, каждый из которых является равноправным ее членом |
|
зависимость между параметризированным абстрактным классом-шаблоном и реальным классом, который инициирует параметры шаблона |
|
совокупность диаграмм, которые визуализируют основные элементы структуры системы |
Диаграмма последовательности задает:
|
поведение системы в виде определенных работ, которые может выполнять система или актер, виды работ могут зависеть от принятия решений в зависимости от заданных условий или ограничений |
|
поведение совокупности объектов, функции которых ориентированы на достижение целей системы, а также взаимосвязи тех ролей, которые обеспечивают сотрудничество |
|
взаимодействие объектов с помощью сценариев, отображающих события, связанные с их созданием и уничтожением |
Транзитивные системы называют бисимуляционно эквивалентными, если:
|
каждое состояние эквивалентно состоянию другой системы |
|
каждое состояние неэквивалентно состоянию другой системы |
|
каждое состояние эквивалентно другой системе |
Технология разработки прикладной системы с использованием АОП включает следующие общие этапы:
|
анализ библиотеки расширений для выбора некоторых функциональных модулей, необходимых для реализации задач ПрО |
|
определение механизмов композиции функциональных модулей многоразового применения и аспектов в точках их соединения |
|
декомпозиция функциональных задач с условием многоразового применения модулей и выделенных аспектов |
|
выбор готовых компонентов с подобными функциями, пригодными для практического применения и настройка их к новым условиям |
Для доказательства правильности спецификации сообщения создается набор утверждений, доказывающий, что:
|
для любой пары элементов сообщения, например, A и B, переход от A к B проходит не менее чем за три шага |
|
для любой пары элементов сообщения, например, A и B, переход от A к B проходит быстрее чем переход от B к A |
|
для любой пары элементов сообщения, например, A и B, переход от A к B проходит за один шаг |
Отображение — это:
|
конструктор union для объединения типов  , при котором тип id получает одно из значений в списке элементов |
|
последовательность значений одного типа listT |
|
структура (map), которая ставит в соответствие значениям одного типа значение другого типа |
Каждый компонент C в ОКМ-модели задается в виде C = (E, I, V, P), где:
|
P — множество состояний, каждое из которых связано с ассоциативным действием |
|
P — множество временных свойств, отражающее особенности среды компонента |
|
P — операции связи для взаимодействия с другими компонентами |
Статический анализ заключается в:
|
накапливании информации об ошибках |
|
проверке прохождения всех путей программ |
|
проверке корректности ПС на множестве тестов |
|
инспекции исходного кода и сквозного контроля программы |
Инспекция ПО — это:
|
динамическая проверка соответствия программы заданным спецификациями |
|
функциональная проверка соответствия программы заданным спецификациями |
|
статическая проверка соответствия программы заданным спецификациями |
В соответствии с международным стандартом ANSI/IEEE-729-83 ошибка (error) — это:
|
состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки |
|
отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями |
|
следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. |
Цель процесса валидации:
|
убедиться, что каждый программный продукт (и/или сервис) проекта отражает согласованные требования к их реализации |
|
убедиться, что специфические требования для программного продукта выполнены |
|
обнаружить ошибки в ПО путем исполнения выходного кода ПС на тестовых данных и сбора рабочих характеристик в динамике выполнения в конкретной операционной среде |
Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 не включает:
|
основные процессы ЖЦ тестирования ПО |
|
планы тестирования различных объектов, необходимые для проведения тестирования ресурсы |
|
тесты, контрольные примеры, критерии и ограничения, оценки результатов программного продукта |
Цель тестирования — это:
|
проверка отражения программным продуктом согласованных требований к его реализации |
|
проверка работы реализованных функций в соответствии с их спецификацией |
|
проверка выполнения специфических требований для программного продукта |
В обязанности инженера-тестировщика не входят:
|
исправление ошибок, выявленных на этапе тестирования |
|
составление плана теста |
|
создание тестовых сценариев |
|
оценка тестов |
Теоретические средства — это:
|
методы верификации и доказательства правильности спецификации программ |
|
организационные средства планирования и отбора тестов для программ |
|
метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) |
Ошибки ввода-вывода и манипулирования данными являются следствием:
|
некачественной подготовки данных для выполнения программы, сбоев при занесении их в базы данных или при выборке из нее |
|
неправильно определенных функций, нарушения порядка их применения или отсутствия полноты их реализации |
|
неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов |
|
того, что реализованные методы доступа и размеры баз данных не удовлетворяют реальным объемам информации системы или интенсивности их обработки |
Систематические методы тестирования делятся на следующие методы:
|
метод «серого ящика» |
|
метод «черного ящика» |
|
метод «белого ящика» |
XDR-стандарт:
|
содержит язык описания структур данных произвольной сложности и средства преобразования данных, передаваемых на платформы |
|
обеспечивает преобразование данных в форматы передающей и принимающей платформ |
|
обеспечивает устранение неоднородности во взаимосвязях компонентов в разных ЯП с помощью формата данных, который учитываются разные платформ и среды |
Операции реверсной инженерии над компонентами удовлетворяют условиям:
|
операция ориентирована на индустриальные системы в миллион строк кода с использованием метрических оценок характеристик системы |
|
написание системной спецификации начинается не с «нуля», а с рассмотрения возможностей старой наследуемой системы |
|
операция не изменяет функциональность компонента и новый компонент может применяться в ранее построенных компонентных системах |
Внутреннее преобразование типов данных обладает следующими свойствами:
|
для каждого внутреннего типа данных преобразование определяет связь между допустимым значением внутреннего типа данных и эквивалентным значением соответствующего LI-типа данных |
|
для каждого значения внутреннего типа данных преобразование определяет, является ли это значение образом (после преобразования) какого-то значения LI-типа данных и его способ преобразования |
|
для каждого LI-типа данных преобразование определяет отношение между допустимым значением этого типа и эквивалентным значением соответствующего внутреннего типа ЯП |
Маршалинг данных — это:
|
прямое и обратное преобразование данных средствами ЯП |
|
преобразование данных к формату данных передавшей клиентской программы |
|
преобразование данных к формату данных принимающей серверной платформы |
Интерфейс в ООП — это:
|
внешнее представление класса |
|
внутреннее представление класса |
|
объект класса |
Интерфейс между Perl и другими ЯП осуществляется с помощью:
|
функций в JNI |
|
интерфейсных функций в С++ |
|
платформенно-ориентированных функций |
Интерфейсные операции класса подразделяются на:
|
приватные, доступные классу |
|
клиентские, различные для разных клиентов |
|
защищенные, доступные классу и подклассу |
|
публичные, доступные всем клиентам |
Независимые от ЯП типы данных стандарта ISO/IEC 11404-1996 делятся на:
|
типы данных высокого уровня |
|
примитивные типы данных |
|
сгенерированные типы данных |
Преобразование данных БД связано с различием логических структур данных, а также со следующими проблемами:
|
различия в логических структурах данных, в справочниках, классификаторах и в системах кодирования информации |
|
многомодельность представления данных (иерархические, сетевые, реляционные) в различных БД и СУБД |
|
различия на этапе разработки СУБД |
ПИК=(T,I,F,R,S), где T — это:
|
реализация, скрытая часть — программный код |
|
тип компонента |
|
множество интерфейсов компонента |
Артефактами деятельности разработчиков ПС могут быть:
|
готовые компоненты ПС или отдельные части системы |
|
интерфейсы ПС |
|
промежуточные продукты процесса разработки ПС |
Поисковый образ упрощает поиск и сокращает сроки разработки ПС за счет:
|
отображения базовых функций и понятий компонента |
|
открытия представления данных |
|
обработки исключительных ситуаций, возникающих в процессе выполнения |
Внутренняя часть компонента — это:
|
интерфейс, который определяет взаимодействие компонента с внешней средой и с платформой, на которой он будет выполняться |
|
программный фрагмент кода, системная или абстрактная структура, представленные в виде каркаса компонента, спецификации и выходного кода |
|
сервис для взаимодействия со средой или набор правил развертывания |
Репозитарий в интегрированной среде ПрО не включает в себя:
|
компоненты ПИК |
|
новые аспекты из семейства ПрО |
|
определение области действий объектов ПрО |
|
аспекты безопасности, защиты, изменения ПИК |
Интенсивность отказов — это:
|
частота появления отказов или дефектов в ПС при ее тестировании или эксплуатации |
|
переход ПС из работающего состояния в нерабочее или когда получаются результаты, которые не соответствуют заданным допустимым значениям |
|
следствие ошибок разработчика на любом из процессов разработки |
Марковская модель:
|
используется тогда, когда интенсивность отказов пропорциональна не только текущему числу ошибок, но и времени, прошедшему с момента последнего отказа |
|
характеризуется дискретным временем и конечным множеством состояний |
|
базируется на выявлении отказов и моделируется неоднородным процессом |
Сколько уровней представления имеет модель качества ПО?
|
2 |
|
5 |
|
3 |
|
4 |
Переносимость — это:
|
группа свойств ПО, обеспечивающая его приспособленность для переноса из одной среды функционирования в другие, усилия для переноса и адаптацию ПО к новой среде функционирования |
|
группа свойств, определяющая усилия, необходимые для выполнения, приспособленность к диагностике отказов и последствий внесения изменений, модификации и аттестации модифицируемого ПО |
|
группа свойств, характеризующаяся степенью соответствия используемых ресурсов среды функционирования уровню качества (надежности) функционирования ПО при заданных условиях применения |
К подхарактеристикам надежности ПО не относится:
|
устойчивость к ошибкам |
|
восстанавливаемость |
|
безотказность |
|
функциональная полнота |
Метрики использования позволяют оценить:
|
свойства программы |
|
результаты эксплуатации программы |
|
сложность внедрения программы |
Результатом управления конфигурацией является:
|
репозитарий базовых библиотек и ресурсов |
|
документ о передаче измененной версии пользователю |
|
отчет о проведенных изменениях версии системы и документации |
Базис конфигурации — это:
|
формально созданная основа (версия) системы из отдельных компонентов и документации, позволяющая проводить дальнейшее развитие системы |
|
элементы конфигурации, выделенные для управления или обработки функций системы на процессорах компьютеров системы |
|
программные компоненты, выполняющие задачи в сформированной версии системы |
Управление проектом — это:
|
процесс распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта |
|
совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС |
|
руководство работами команды исполнителей проекта для реализации проекта с использованием методов управления, планирования и контроля работ, управление рисками, эффективной организацией работы и коммуникационными потоками в команде исполнителей |
Ответственность за идейную, функциональную сторону проекта несет:
|
главный программист |
|
системный администратор |
|
менеджер проекта |
Суть учета статуса состоит в:
|
регистрации и предоставлении информации для эффективного управления конфигурацией |
|
рассмотрении и оценке документации |
|
ревизии или проверке очередной версии ПО перед сдачей системы заказчику |
Поддержка темпа работы не предполагает:
|
управление процессом разработки продукта, а не людьми команды |
|
контроль качества выполняемых работ |
|
постоянный контроль за использованием работниками рабочего времени |
|
уменьшение текучести кадров |
Количественная оценка рисков — это:
|
разработка методов и технологий снижения отрицательного воздействия рисков на проект |
|
процесс принятия решений по применению и планированию управления рисками для конкретного проекта |
|
процесс определения вероятности возникновения рисков, влияния последствий рисков на проект и принятия решений по оценке риска |
Модель производственной архитектуры — это:
|
модель, определяющая роли, обязанности каждого участника проекта и распределение между ними ответственности |
|
набор принципов, обеспечивающих создание версии производственной архитектуры предприятия |
|
трехуровневая структура, сценарный метод проектирования и разработки приложения |
Exception — это:
|
шаблон для создания класса, его исключений и выдачи сообщений об ошибках, которые могут обнаружиться в программе |
|
шаблон, который помогает создать новый JAVA интерфейс и использовать его любым классом через ключевое слово implements |
|
шаблон, позволяющий отобразить реляционную схему и использовать ее для создания БД без подключения к MySQL |
Компоненты сущностей:
|
функционируют для получения сообщений, поступающих от системы обмена сообщениями JMS (Java Messaging System), и реагируют на них |
|
поддерживают правила бизнеслогики, ориентированы на состояния и могут быть связаны с конкретным клиентским сеансом |
|
используются для связи с БД непосредственно и предоставляют данные в объектной форме |
Client class — это:
|
шаблон интеграции компонентов в системе CORBA, для вызова метода, который будет выполнен сервером |
|
шаблон интеграции компонентов в системе CORBA, обеспечивает конвертирование данных метода, инициирующего работу клиента в Wire формате, используемом при связывании на стороне клиента сети |
|
шаблон интеграции компонентов в системе CORBA, управляет методами передачи данных и вызовами методов между процессами |
Модель процесса разработки ПО — это:
|
модель, определяющая структуру процессов и руководство ими в течение всего времени жизни проекта |
|
модель, с помощью которой определяется порядок и условия реализации упреждающих решений и мер по выявлению наиболее существенных моментов риска |
|
модель, определяющая цели и задачи процесса разработки производственной архитектуры с параллельным и итерационным выполнением отдельных работ |
CustomTask — это:
|
шаблон развертывания компонентов, разрешающий сконфигурировать общую схему проекта с помощью иерархии системы файлов как корневой узел схемы нового проекта. Затем в проект добавляются новые компоненты, они пакетируются и делается их детальный просмотр |
|
шаблон развертывания компонентов, создающий проект, который не содержит в себе ни одного класса или пакета классов, разрешающий подключать новые классы и пакеты в схему проекта |
|
шаблон развертывания компонентов, позволяющий создать новый проект, начиная с формирования первоначального класса в этом проекте |
Какие модели создаются в процессе моделирования?
|
модель анализа |
|
модель реализации |
|
модели вариантов использования |
|
модель проектирования |
|
модель размещения компонентов |
Компоненты сеансов:
|
используются для связи с БД непосредственно и предоставляют данные в объектной форме |
|
поддерживают правила бизнеслогики, ориентированы на состояния и могут быть связаны с конкретным клиентским сеансом |
|
функционируют для получения сообщений, поступающих от системы обмена сообщениями JMS (Java Messaging System), и реагируют на них |
Модель проектной группы — это:
|
набор принципов, обеспечивающих создание версии производственной архитектуры предприятия |
|
модель, определяющая роли, обязанности каждого участника проекта и распределение между ними ответственности |
|
трехуровневая структура, сценарный метод проектирования и разработки приложения |
