МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

«ДАГЕСТАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

Факультет информатики и информационных технологий

Кафедра информатики и информационных технологий

Тестовые задания по дисциплине

Технологии и методы программирования

Направление090900.62 Информационная безопасность

Профиль подготовки: Безопасность компьютерных систем

Степень выпускника: Бакалавр

Форма обучения: очная

Модуль 1.Понятия программной инженерии. Методология MSF

Программное обеспечение это:

1. набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207)

2. программа на языке программирования Basic

3. программа с пользовательским интерфейсом, и файлом справки

Определению технологии соответствует:

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

2. наука изучающая технику

3. качественный подход к принятию решения в сложной обстановке

Сколько входов в цикл возможно при написании блок схемы?

1. два и более

2. два

3. один

Основные принципы объектной модели:

1. абстракция

2. инкапсуляция

3. иерархия

4. модульность

5. размножимость

6. полиморфизм

Отличие компонентного от объектно-ориентированного программирования:

1. введен следующий уровень абстракции - классы объединяются в компоненты

2. отменена иерархия

3. поддерживается спиральная модель

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

1. ранжированная система абстракций

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

3. процесс выделения абстракций в предметной области

Объект это

1. переменная типа класса

2. противоположность субъекту

3. сущность сущностей ООП

Полиморфизм бывает:

1. сложный обособленный

2. чистый

3. перегрузка

4. простой (переопределение)

Объектно-ориентированная технология работает на стадиях

1. анализа

2. проектирования

3. программирования

Программное обеспечение это:

1. набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207)

2. программа на языке программирования Basic

3. программа с пользовательским интерфейсом, и файлом справки

Предметная область software engineering:

1. часть system engineering, имеющая дело с разработкой ПО

2. теория и основы разработки ПО

3. вопросы разработки систем с участием компьютеров

Формализация процесса создания ПО оправдана для коллектива

1. более 20-ти человек

2. 5-6-ти человек

3. 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. для очень больших команд

2. для малых и средних

3. для малых групп разработчиков

Модель пошаговой разработки требует

1. в итоге каждого шага - работающий прототип

2. использовать для каждого шага каскадную модель

3. использовать для каждого шага эволюционную модель

Для каждого шага модели пошаговой разработки можно применять

1. каскадную модуль

2. объектную модель

3. эволюционную модель

Процесс создания программного обеспечения -

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

2. написание кода на каком-либо языке программирования

3. процесс выделения абстракций в предметной области

Модель процесса создания ПО -

1. представление процесса, рассматривающее состав этапов и способы их претворения в жизнь

2. описание тех или иных программных решений

3. модель на языке ассемблер

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

1. реализации

2. аттестации

3. спецификации

Объектно-ориентированный анализ - это

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

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

3. анализ подготовленный по стандарту UML

Открытые атрибуты отмечаются

1. "+"

2. "#"

3. "-"

Объектно-ориентированное программирование - это

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

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

3. современная технология, наиболее актуально представленная в UML

Диаграмма состояния -

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

2. показывает работу системы с точки зрения пользователей

3. показывает потоки информации в системе

Диаграмма компонентов -

1. показывает компоненты и связи между ними

2. показывает внутреннюю структуру классов и связи с внешним миром

3. показывает классы, их атрибуты и связи между классами

Стандарт UML 2.0 был принят в

1. марте 2006

2. октябре 2004

3. марте 2003

Кардинальность N:M

1. не является кардинальностью вообще

2. нет такой кардинальности

3. может быть представлена связью 0..* с 0..*

Зависимость между сущностями графически оформляется как

1. пунктирная линия со стрелкой

2. ненаправленная линия

3. пунктирная ненаправленная линия

Агрегация это

1. предположение о том, что 0 или более объектов включены в 1 и более объектов другого типа

2. каждый объект второго типа может быть включен ровно в 1 объект первого типа

3. соединение выборок

Суть инкапсуляции в объектном подходе -

1. скрытие деталей внутренней реализации

2. вложенность меньшего в большее

3. сложность при соединении большего с меньшим классом

Смысл полиморфизма в объектном подходе -

1. выбор метода родительского класса

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

3. выбор наиболее близкого к родительскому классу метода

Microsoft Operations Framework (MOF) предлагает рекомендации помогающие обеспечеть

1. надежность решений

2. доступность решений

3. удобство в сопровождении

4. управляемость

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

1. 6 человек

2. 4 человека

3. 3 человека

MSF for Agile Software Development - это

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

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

3. это Extreme Programming

Концепции MSF при построении команды

1. концентрация на нуждах заказчика

2. стремление к самосовершенствованию

3. строгая иерархичность

Концепции MSF при построении команды

1. нацеленность на конечный результат

2. установка на отсутствие дефектов

3. "проектная группа - команда равных"

Зона ответственности управления командой, в MSF 4.0 -

1. управление проектом, воплощение в жизнь ожиданий заинтересованных сторон

2. система в целом

3. понимание потребностей пользователей, их реализация

Зона ответственности группы тестирования, в MSF 4.0 -

1. гладкое внедрение решения в инфраструктуру заказчика

2. разработка системы в целом

3. качество решения с точки зрения заказчика и будущих пользователей

Ролевая группа управление программой, в MSF 4.0, выполняет задачи:

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

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

3. определяет структуру развертывания (внедрения) решения

Ролевая группа тестирования, в MSF 4.0, выполняет задачи:

1. определяет детали физического дизайна

2. разрабатывает или контролирует разработку элементов

3. осуществляет тестирование

Ролевая группа управление выпуском, в MSF 4.0, выполняет задачи:

1. представляет интересы отделов поставки и обслуживания продукта

2. организует снабжение проектной группы

3. организует сопровождение и инфраструктуру поставки

Ролевая группа управление продуктом, в MSF 4.0, выполняет задачи:

1. выступает в роли представителя заказчика

2. организует работу с требованиями заказчика

3. формирует ожидания заказчика

Решение о объеме работ принимает

1. заказчик

2. ролевая группа разработка

3. ролевая группа архитектура

MSF основывается на утверждении

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

2. каждый ролевой кластер представляет уникальную точку зрения на проект

3. каждый ролевой кластер имеет равные права

Последняя версия Microsoft Solutions Framework (MSF) датируется

1. 2005 г

2. 2003 г

3. 2002 г

Зона ответственности разработки, в MSF 4.0 -

1. отвечает за проектирование и осуществление реализации

2. качественные показатели решения

3. система в целом, выработка архитектуры

Зона ответственности группы управления выпуском, в MSF 4.0 -

1. проектирование и осуществление реализации

2. понимание потребностей пользователей и их надлежащую реализацию в решении

3. гладкое внедрение решения в инфраструктуру заказчика

Ролевая группа архитектура проекта, в MSF 4.0, выполняет задачи:

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

2. определяет структуру развертывания (внедрения) решения

3. определяет детали физического дизайна

Ролевая группа удовлетворение потребителя, в MSF 4.0, выполняет задачи:

1. выступает в роли представителя заказчика

2. организует работу с требованиями пользователя

3. представляет интересы потребителя в команде

Ролевая группа управление продуктом, в MSF 4.0, выполняет задачи:

1. формирует общее видение и рамки проекта

2. организует маркетинг

3. разрабатывает стратегию и планы тестирования

4. организует внедрение продукта

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

Модуль 2. Разработка и оценка качества программного обеспечения

Дисциплина управления рисками в MSF for Agile Software Development это

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

2. дисциплина, используемая на стадии проектирования проекта

3. дисциплина, используемая на стадии сдачи проекта

Цель управления рисками -

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

2. избежать рисков

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

Дисциплина управления рисками MSF представляет собой

1. процесс из шести шагов: выявление, анализ и приоритезация, планирование, мониторинг и отчетность, корректирование, извлечение уроков, выявление

2. процесс из 3-х шагов: анализ, мониторинг, выявление

3. процесс из 3-х шагов: мониторинг, анализ, выявление

Мониторинг рисков (risk tracking) -

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

2. этап, предшествующий анализу рисков

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

Корректирование ситуации (risk control) -

1. включает в себя инициирование изменений всего проекта

2. процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения

3. предшествует этапу мониторинга

"Вехи" (milestones) -

1. точка этапа каскадной модели

2. ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата

3. конечная точка этапа - та точка возвращение к которой не требуется

Треугольник компромиссов образуют

1. ресурсы, время, возможности

2. грамотное управление, ресурсы, время

3. время, возможности, грамотное управление

Принципы модели процессов:

1. уменьшайте количество "вех"

2. создавайте "единое видение проекта"

3. следите за качеством продукта

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

1. ресурсы наиболее приоритетны

2. наиболее приоритетно уложиться в календарный график

3. наименее приоритетно работать над функциональностью

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

1. влиять на ресурсы невозможно

2. наиболее изменяемы ресурсы

3. наиболее изменяем функционал

Особенности "вех":

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

2. в MSF используются обобщенные главные вехи, большинство из которых применимо к любому типу IT проектов

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

Основные характеристики дисциплины управления рисками в MSF:

1. возможность оценить риски на первом этапе и не возвращаться более к этой процедуре

2. она вовлекает всю проектную группу в непрерывное извлечение уроков из полученного опыта

3. она превентивна и не исходит из идеологии действия по факту случившегося

Цель управления рисками -

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

2. избежать рисков

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

Ключевые концепции дисциплины управления рисками MSF -

1. риск - неотъемлемая часть всякого проекта или процесса

2. выявление рисков нужно всячески одобрять

3. оценка рисков должна вестись постоянно

4. риск - это проблема требующая решения, во время возникновения

Выявление рисков (risk identification) -

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

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

3. этап, предшествующий анализу рисков

Планирование рисков (risk planning) -

1. имеет целью выработку стратегий

2. предшествует этапу извлечения уроков

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

Корректирование ситуации (risk control) -

1. включает в себя инициирование изменений всего проекта

2. процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения

3. предшествует этапу мониторинга

Процесс MSF ориентирован на

1. бизнес-отдаче (business value) решения

2. понимание потребностей пользователей

3. "вехи" (milestones) - ключевые точки проекта

Треугольник компромиссов образуют

1. ресурсы, время, возможности

2. грамотное управление, ресурсы, время

3. время, возможности, грамотное управление

Принципы модели процессов:

1. уменьшайте количество "вех"

2. создавайте "единое видение проекта"

3. следите за качеством продукта

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

1. ресурсы наиболее приоритетны

2. наиболее приоритетно уложиться в календарный график

3. наименее приоритетно работать над функциональностью

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

1. влиять на ресурсы невозможно

2. наиболее изменяемы ресурсы

3. наиболее изменяем функционал

Типы "вехи"

1. главные (major)

2. конечные (finite)

3. промежуточные (interim)

Особенности "вех":

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

2. промежуточные вехи могут варьироваться от проекта к проекту

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

Календарное планирование рисков (risk scheduling) -

1. составление календарного графика прошедших рисков

2. составление календарного графика будущих рисков

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

"Вехи" (milestones) -

1. точка этапа каскадной модели

2. ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата

3. конечная точка этапа - та точка возвращение к которой не требуется

Треугольник компромиссов - это

1. взаимосвязь любых трех ключевых моментов выработанных в процессе работы над проектом

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

3. взаимосвязь трех и более ключевых моментов проекты

Принципы модели процессов:

1. будьте готовы к внедрению сегодня

2. будьте готовы к внедрению сегодня

3. ставьте "вехи"

Матрица компромиссов проекта:

1. полезное средство управления проектными компромиссами

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

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

Особенности модели MSF -

1. итеративный подход

2. подход, основанный на фазах и вехах

3. интегрированный подход к созданию и внедрению решений

Особенности "вех":

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

2. в MSF используются обобщенные главные вехи, большинство из которых применимо к любому типу IT проектов

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

Дисциплина управления рисками в MSF for Agile Software Development это

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

2. дисциплина, используемая на стадии проектирования проекта

3. дисциплина, используемая на стадии сдачи проекта

Риск проекта (project risk) - это

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

2. риск это не проблема

3. риск это проблема

Мониторинг рисков (risk tracking) -

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

2. этап, предшествующий анализу рисков

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

Извлечение уроков (risk learning) -

1. предшествует этапу мониторинга

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

3. следует за этапом мониторинга

Принципы модели процессов:

1. взаимодействуйте с заказчиками

2. поощряйте свободный обмен информацией в проекте

3. устраивайте корпоративный вечеринки

Итеративными методами как правило создаются

1. программный код

2. документация

3. дизайн

Этапы процесса управления рисками модели MSF

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

2. являются логическими шагами и обязаны следовать друг за другом

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

Дисциплина управления рисками MSF представляет собой

1. процесс из шести шагов: выявление, анализ и приоритезация, планирование, мониторинг и отчетность, корректирование, извлечение уроков, выявление

2. процесс из 3-х шагов: анализ, мониторинг, выявление

3. процесс из 3-х шагов: мониторинг, анализ, выявление

Модель процессов MSF (MSF process model) сочетает в себе

1. свойства каскадной и итерационной моделей

2. свойства спиральной и итерционной моделей

3. свойства каскадной и спиральной моделей

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

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

2. цели дизайна; концепция решения; структура проекта

3. прототипирование; анализ технологических возможностей; анализ осуществимости

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

1. стратегии тестирования; критерии приемлемости, их влияние на разработку решения

2. цели дизайна; концепция решения; структура проекта

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

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

1. цели дизайна; концепция решения; структура проекта

2. прототипирование; анализ технологических возможностей; анализ осуществимости

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

Рамки решения (solution scope) -

1. определяют функциональность решения и его требуемые или желаемые аспекты

2. тоже что и рамки (scope)

3. тоже что и рамки решения (solution scope

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

1. концептуальный дизайн; анализ бизнес-требований; коммуникационный план

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

3. оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates)

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

1. сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение

2. оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения

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

Результаты фазы выработки концепции:

1. общее описание и рамки проекта (vision/scope document)

2. описание структуры проекта (project structure document)

3. функциональная спецификация

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

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

2. рекомендуемая стандартом MSF веха

3. не рекомендуемая стандартом MSF веха

Промежуточная веха - средства разработки и тестирования развернуты -

1. настроено необходимое для разработки аппаратно-программное обеспечение

2. веха не рекомендуется стандартом MSF

3. веха рекомендуется стандартом MSF

Процесс проектирования начинается с

1. с написания сценариев использования

2. c написания рабочих сценариев

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

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

1. ожидания заказчика

2. управление функциональной спецификацией; мониторинг проекта; доработка планов

3. разработка программного кода и инфраструктуры; документирование конфигураций

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

1. обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн

2. функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования

3. чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists)

Результаты фазы разработки

1. исходный и исполнительный код приложений

2. скрипты установки и конфигурирования

3. окончательная функциональная спецификация

Прохождение вехи "Готовность решения утверждена", в модели MSF, целесообразно

1. когда все известные проблемы разрешены

2. когда проект получает статус "бета"

3. когда проект получает статус "каппа"

Результаты фазы стабилизации -

1. окончательный продукт

2. документации выпуска

3. проект в стадии "Каппа"

Основные задачи и сферы ответственности ролевого кластера разработка, в модели MSF, во время фазы стабилизации

1. исполнение коммуникационного плана; планирование премьеры продукта

2. устранение ошибок; оптимизация программного кода

3. мониторинг проекта; приоритезация ошибок

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

1. тестирование; сообщение об ошибках и их статусе; тестирование конфигурации