Тамбовское областное государственное бюджетное

профессиональное образовательное учреждение

«Уваровский химико-технологический колледж»

РАССМОТРЕНО ОДОБРЕНО:

Предметно-цикловой комиссией

_информационных технологий_

Протокол №_______________

от «__»_______________ 2019г.

Председатель ПЦК____________

УТВЕРЖДАЮ:

Директор ТОГБПОУ УХТК

____________Н.А.Ермакова

«__»_______________ 2019г.

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

ПМ 3 Ревьюирование программных продуктов

основной профессиональной образовательной программы (ОПОП) по

направлению подготовки (специальности)

по специальности СПО

09.02.07 «Информационные системы и программирование»

(код, название)

1

СОДЕРЖАНИЕ

1 ПАСПОРТ КОНТРОЛЬНО-ИЗМЕРИТЕЛЬНЫХ МАТЕРИАЛОВ ............................3

2 КОМПЛЕКТ МАТЕРАЛОВ ДЛЯ ТЕКУЩЕЙ АТТЕСТАЦИИ ...................................5

3КОМПЛЕКТ МАТЕРАЛОВ ДЛЯ ПРОМЕЖУТОЧНОЙ АТТЕСТАЦИИ ………….10

2

1 ПАСПОРТ КОНТРОЛЬНО-ИЗМЕРИТЕЛЬНЫХ МАТЕРИАЛОВ

Контрольно-

измерительные

материалы

предназначены

для

проверки

результатов

освоения

профессионального модуля ПМ.03 Ревьюирование программных продуктов программы

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

системы и программирование. Контрольно-измерительные материалы позволяют оценивать

освоение умений и усвоение знаний по междисциплинарному курсу.

1.1 Контроль и оценка результатов освоения

Результаты обучения (освоенные умения,

усвоенные знания)

Формы и методы контроля и оценки

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

В результате изучения профессионального

модуля обучающийся должен уметь:

работать с проектной документацией,

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

графических языков спецификаций;

• выполнять оптимизацию программного

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

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

• использовать методы и технологии

тестирования и ревьюирования кода и

проектной документации;

• применять стандартные метрики по

прогнозированию затрат, сроков и качества

Тестирование

Практическое задание

Дифференцированный зачет

В результате изучения профессионального

модуля обучающийся должен

Знать:

• задачи планирования и контроля развития

проекта;

• принципы построения системы

деятельностей программного проекта;

• современные стандарты качества

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

обеспечения

Тестирование

Практическое задание

Дифференцированный зачет

1.2 Организация промежуточного контроля

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

дифференцированного зачёта.

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

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

1.3. Освоение профессиональных и общих компетенций

Наименование результата обучения

Средства проверки

ПК 3.1 Осуществлять ревьюирование

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

технической документацией

Вопросы для текущего контроля

Тесты

Практическое задание

ПК.3.2 Выполнять измерение

характеристик компонент программного

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

заданным критериям

Вопросы для текущего контроля

Тесты

Практическое задание

ПК.3.3 Производить исследование

Вопросы для текущего контроля

3

созданного программного кода с

использованием специализированных

программных средств с целью выявления

ошибок и отклонения от алгоритма

Тесты

Практическое задание

ПК.3.4 Проводить сравнительный анализ

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

разработки, с целью выявления наилучшего

решения согласно критериям,

определенным техническим заданием

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 1 Выбирать способы решения задач

профессиональной деятельности,

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

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 2 Осуществлять поиск, анализ и

интерпретацию информации, необходимой

для выполнения задач профессиональной

деятельности

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 3 Планировать и реализовывать

собственное профессиональное и

личностное развитие

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 4 Работать в коллективе и команде,

эффективно взаимодействовать с

коллегами, руководством, клиентами

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 5 Осуществлять устную и письменную

коммуникацию на государственном языке с

учетом особенностей социального и

культурного контекста.

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 6 Проявлять гражданско-

патриотическую позицию, демонстрировать

осознанное поведение на основе

традиционных общечеловеческих

ценностей

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 7 Содействовать сохранению

окружающей среды, ресурсосбережению,

эффективно действовать в чрезвычайных

ситуациях

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 8 Использовать средства физической

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

здоровья в процессе профессиональной

деятельности и поддержания необходимого

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

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 9 Использовать информационные

технологии в профессиональной

деятельности

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 10 Пользоваться профессиональной

документацией на государственном и

иностранном языке

Вопросы для текущего контроля

Тесты

Практическое задание

ОК 11 Планировать предпринимательскую

деятельность в профессиональной сфере

Вопросы для текущего контроля

Тесты

Практическое задание

4

2

КОМПЛЕКТ МАТЕРИАЛОВ ДЛЯ ТЕКУЩЕЙ АТТЕСТАЦИИ

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

Процесс построения информационных

моделей с помощью формальных языков

называют

имитационное моделирование применяют

в случаях

метод построения информационных систем

Многокомпонентная система

Автоматизированная система

моделирования (АСМ)

В основе Объектно-ориентированого

подхода лежат понятия

жизненный цикл Объектно-

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

проектирование

Для чего нужно моделирование

программного обеспечения

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

Для создания описательных текстовых

информационных моделей обычно

используют

Модели, построенные с использованием

математических понятий и формул,

называют

метод построения информационных систем

Метод “снизу-вверх”

Каскадная модель ИС

Автоматизированная система

моделирования (АСМ) Функциональное

наполнение

жизненный цикл Объектно-

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

Программирование, тестирование и

сборка системы

Для чего нужно моделирование

программного обеспечения

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

Основное отличие формальных языков от

естественных состоит

Концептуально-методологическое

моделирование представляет собой

метод построения информационных систем

Метод “сверху-вниз”

Поэтапная (итерационная) модель ИС с

промежуточным контролем

Автоматизированная система

моделирования (АСМ) Системное

наполнение

жизненный цикл Объектно-

ориентированого подхода анализ

5

Для чего нужно моделирование

программного обеспечения

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

Модели, построенные с использованием

математических понятий и формул,

называют

метод построения информационных систем

Принципы “дуализма” и

многокомпонентности

Концептуально-методологическое

моделирование представляет собой

имитационное моделирование применяют

в случаях

Автоматизированная система

моделирования (АСМ) Язык заданий (ЯЗ)

Преимущества Объектно-

ориентированого подхода Повторное

использование

Для чего нужно моделирование

программного обеспечения

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

Концептуально-методологическое

моделирование представляет собой

метод построения информационных систем

Принципы “дуализма” и

многокомпонентности

метод построения информационных систем

Многокомпонентная система

Автоматизированная система

моделирования (АСМ) Язык заданий (ЯЗ)

Преимущества Объектно-

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

Распараллеливание работ

жизненный цикл Объектно-

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

Программирование, тестирование и

сборка системы

Для чего нужно моделирование

программного обеспечения

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

С помощью формальных языков строят

информационные модели определённого

типа

Концептуальное

моделирование представляет собой

Каскадная модель ИС

В основе Объектно-ориентированого

подхода лежат понятия

Преимущества Объектно-

ориентированого подхода Повторное

6

использование

жизненный цикл Объектно-

ориентированого подхода анализ

Для чего нужно моделирование

программного обеспечения

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

Наряду с естественными языками (русский,

английский и т.д.) разработаны и

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

Процесс построения информационных

моделей с помощью формальных языков

называют

имитационное моделирование на ЭВМ

метод построения информационных систем

Метод “сверху-вниз”

Поэтапная (итерационная) модель ИС с

промежуточным контролем

Преимущества Объектно-

ориентированого подхода Повторное

использование

Для чего нужно моделирование

программного обеспечения

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

Модели, построенные с использованием

математических понятий и формул,

называют

Концептуальное

моделирование представляет собой

имитационное моделирование применяют

в случаях

метод построения информационных систем

Многокомпонентная система

Автоматизированная система

моделирования (АСМ)

Преимущества Объектно-

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

Распараллеливание работ

Для чего нужно моделирование

программного обеспечения

Ролевой состав коллектива разработчиков,

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

технологических процессах

Заказчик (заявитель).

Менеджер проекта

Менеджер программы

Разработчик.

Специалист по тестированию

Специалист по контролю качества.

Специалист по сертификации.

7

Специалист по внедрению и

сопровождению

Специалист по безопасности

Инструктор

Технический писатель

цели верификации

Задачи процесса верификации

Основная идея в тестировании системы, как

черного ящика состоит в том, что

С точки зрения программного кода черный

ящик может представлять собой

При тестировании системы, как

стеклянного ящика, тестировщик имеет

доступ

Тестирование моделей позволяет

тестировщику

Анализ программного кода (инспекции)

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

Тестовое окружение может использоваться

для

Целью тестирования тестового окружения

является

Тестовые вопросы.

1.Модель может быть построена для любого

Вариант1= объекта, явления или процесса

Вариант2= объекта или процесса

Вариант3= объекта или явления

Вариант4= объекта

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

существенные признаки, называется

Вариант1= реализацией

Вариант2= упрощением

Вариант3= микромоделированием

Вариант4= моделированием

3.Формализация в процессе моделирования это

Вариант1= процесс замещения оригинала его аналога

Вариант2= комплексирование с уже имеющимися реальными системами

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

Вариант4= постановка различных задач и решение их на модели

4.Процесс моделирования это

Вариант1= постановка различных задач и решение их на модели

Вариант2= проектирование и настройка модели

Вариант3= комплексирование с уже имеющимися реальными системами

Вариант4= процесс замещения оригинала его аналога

5.Процесс интерпретации результатов моделирования это

Вариант1= постановка различных задач и решение их на модели

Вариант2= проектирование и настройка модели

Вариант3= комплексирование с уже имеющимися реальными системами

Вариант4= процесс замещения оригинала его аналога

8

6.Принцип моделирования ПО – правильно выбранная модель позволит проникнуть в

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

Вариант1= возможность рассматривать систему на разных уровнях детализации

Вариант2= модели могут создаваться и изучаться по отдельности, но остаются

взаимосвязанными

Вариант3= выбор модели оказывает влияние на решение проблем

Вариант4= необходимо объединить все независимые представления системы в единое целое

7.Принцип моделирования ПО– каждая модель может быть представлена с различной

степенью точности

Вариант1= модели могут создаваться и изучаться по отдельности, но остаются

взаимосвязанными

Вариант2= возможность рассматривать систему на разных уровнях детализации

Вариант3= необходимо объединить все независимые представления системы в единое целое

Вариант4= выбор модели оказывает влияние на решение проблем

8.Принцип моделирования ПО - лучшие модели те, что ближе к реальности

Вариант1= выбор модели оказывает влияние на решение проблем

Вариант2= модели могут создаваться и изучаться по отдельности, но остаются

взаимосвязанными

Вариант3= возможность рассматривать систему на разных уровнях детализации

Вариант4= необходимо объединить все независимые представления системы в единое целое

9.Принцип моделирования ПО – нельзя ограничиваться созданием только одной модели

Вариант1= необходимо объединить все независимые представления системы в единое целое

Вариант2= возможность рассматривать систему на разных уровнях детализации

Вариант3= выбор модели оказывает влияние на решение проблем

Вариант4= модели могут создаваться и изучаться по отдельности, но остаются

взаимосвязанными

10.Алгоритмический подход моделирования при разработке ПО

Вариант1= основным строительным блоком является процедура или функция

Вариант2= основным строительным блоком является объект или класс

11.Объектно-ориентированный подход моделирования при разработке ПО

Вариант1= основным строительным блоком является процедура или функция

Вариант2= основным строительным блоком является объект или класс

12.Свойство объектов и классов при объектно-ориентированном моделировании ПО

инкапсуляция - это

Вариант1= скрытие объектом внутренней информации от внешнего мира

Вариант2= возможность создавать из классов новые классы по принципу «от общего к

частному»

13.Свойство объектов и классов при объектно-ориентированном моделировании ПО –

наследование это

Вариант1= скрытие объектом внутренней информации от внешнего мира

Вариант2= возможность создавать из классов новые классы по принципу «от общего к

частному»

14.Преимущество методологии объектно-ориентированного программирования -

повторное использование

Вариант1= когда изменение носит характер уточнения, детализации, вводятся новые классы,

наследующие поведение ранее созданных

Вариант2= при наличии развитых библиотек классов проектирование и программирование

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

Вариант3= программирование и тестирование отдельных компонент системы возможно до

завершения проектирования целевой программной системы

15.Преимущество методологии объектно-ориентированного программирования -

упрощение внесения изменений

9

Вариант1= при наличии развитых библиотек классов проектирование и программирование

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

Вариант2= когда изменение носит характер уточнения, детализации, вводятся новые классы,

наследующие поведение ранее созданных

Вариант3= программирование и тестирование отдельных компонент системы возможно до

завершения проектирования целевой программной системы

16.Преимущество методологии объектно-ориентированного программирования -

распараллеливание работ

Вариант1= когда изменение носит характер уточнения, детализации, вводятся новые классы,

наследующие поведение ранее созданных

Вариант2= программирование и тестирование отдельных компонент системы возможно до

завершения проектирования целевой программной системы

Вариант3= при наличии развитых библиотек классов проектирование и программирование

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

Вариант3= при наличии развитых библиотек классов проектирование и программирование

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

17.Ролевой состав коллектива разработчиков. Заказчик (заявитель).

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

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

Вариант2= ограничен в своем взаимодействии и общается только с менеджерами проекта и

специалистом по сертификации или внедрению.

Вариант3= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

Вариант4= Участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

18.Ролевой состав коллектива разработчиков. Менеджер проекта.

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

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

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

Вариант3= ограничен в своем взаимодействии и общается только с менеджерами проекта и

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

Вариант4= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

19.Ролевой состав коллектива разработчиков. Менеджер программы

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

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

Вариант2= ограничен в своем взаимодействии и общается только с менеджерами проекта и

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

Вариант3= управляет коммуникациями и взаимоотношениями в проектной группе, является

координатором

Вариант4= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

20.Ролевой состав коллектива разработчиков. Разработчик.

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

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

Вариант2= ограничен в своем взаимодействии и общается только с менеджерами проекта и

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

Вариант3= Участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант4= несет обязанности по подготовке документации к разработанному

21. Ролевой состав коллектива разработчиков. Специалист по тестированию.

Вариант1= несет обязанности по подготовке документации к разработанному продукту

10

Вариант2= Участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант3= ограничен в своем взаимодействии и общается только с менеджерами проекта и

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

Вариант4= определяет стратегию тестирования, тест-требования и тест-планы для каждой из

фаз проекта

22.Ролевой состав коллектива разработчиков. Специалист по контролю качества.

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

специалистами по безопасности и сертификации

Вариант2= участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант3= несет обязанности по подготовке документации к разработанному продукту

Вариант4= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

23.Ролевой состав коллектива разработчиков. Специалист по сертификации.

Вариант1= Участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант2= несет обязанности по подготовке документации к разработанному продукту

Вариант3= обеспечивает коммуникационный канал между заказчиком и проектной группой

Вариант4= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

24.Ролевой состав коллектива разработчиков. Специалист по внедрению и

сопровождению.

Вариант1= несет обязанности по подготовке документации к разработанному продукту

Вариант2= участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант3= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

Вариант4= обеспечивает коммуникационный канал между заказчиком и проектной группой

25.Ролевой состав коллектива разработчиков. Специалист по безопасности.

Вариант1= ответственен за весь спектр вопросов безопасности создаваемого продукта

Вариант2= участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант3= несет обязанности по подготовке документации к разработанному продукту

Вариант4= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

26.Ролевой состав коллектива разработчиков. Инструктор.

Вариант1= отвечает за снижение затрат на дальнейшее сопровождение продукта, обеспечение

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

Вариант2= Участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант3= приводит документацию на программную систему в соответствие требованиям

сертифицирующего органа

Вариант4= обеспечивает коммуникационный канал между заказчиком и проектной группой

27.Ролевой состав коллектива разработчиков. Технический писатель.

Вариант1= участвует в анализе особенностей площадки заказчика, на которой планируется

проводить внедрение разрабатываемой системы

Вариант2= обеспечивает коммуникационный канал между заказчиком и проектной группой

Вариант3= управляет коммуникациями и взаимоотношениями в проектной группе, является

координатором

Вариант4= несет обязанности по подготовке документации к разработанному продукту

28.Тестирование программного обеспечения

Вариант1= проверка соответствия системы ожиданиям заказчика

11

Вариант2= включает в себя инспекции, тестирование кода, анализ результатов тестирования,

формирование и анализ отчетов о проблемах

Вариант3= управляемое выполнение программы с целью обнаружения несоответствий ее

поведения и требований

29.Верификация программного обеспечения

Вариант1= включает в себя инспекции, тестирование кода, анализ результатов тестирования,

формирование и анализ отчетов о проблемах

Вариант2= управляемое выполнение программы с целью обнаружения несоответствий ее

поведения и требований

Вариант3= проверка соответствия системы ожиданиям заказчика

Вариант4=

30.Валидация программной системы

Вариант1= проверка соответствия системы ожиданиям заказчика

Вариант2= управляемое выполнение программы с целью обнаружения несоответствий ее

поведения и требований

Вариант3= включает в себя инспекции, тестирование кода, анализ результатов тестирования,

формирование и анализ отчетов о проблемах

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

Вариант1= система целиком

Вариант2= небольшие модули

Вариант3= тестируется вся программа в целом

32.Интеграционное тестирование

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

Вариант2= тестируются небольшие модули

Вариант3= тестируется система в целом

33. Системное тестирование

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

Вариант2= тестируются небольшие модули

Вариант3= тестируется система в целом

34.Целью тестов для нормальных ситуаций является

Вариант1= демонстрация способности программного обеспечения адекватно реагировать на

ненормальные входы и условия

Вариант2= демонстрация способности программного обеспечения давать отклик на

нормальные входы и условия в соответствии с требованиями.

35.Целью тестов для ненормальных ситуаций является

Вариант1= демонстрация способности программного обеспечения давать отклик на

нормальные входы и условия в соответствии с требованиями

Вариант2= демонстрация способности программного обеспечения адекватно реагировать на

ненормальные входы и условия

36.Сертификация ПО

Вариант1= процесс установления того, что разработка ПО проводилась в соответствии с

определенными требованиями

Вариант2= процесс установления и официального признания того, что разработка ПО

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

Вариант3= процесс официального признания того, что разработка ПО проводилась в

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

37.Если сертификация направлена на получение сертификата соответствия

Вариант1= то результатом сертификации является признание соответствия процессов

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

требованиям.

Вариант2= то результатом является признание соответствия процессов разработки

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

продукции

12

38.Если сертификация направлена на получение сертификата качества

Вариант1= то результатом является признание соответствия процессов разработки

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

продукции

Вариант2= то результатом сертификации является признание соответствия процессов

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

требованиям

39.Тестирование программного кода это процесс

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

нем дефектов

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

дефектов

40.Под дефектом программного кода понимается

Вариант1= участок программного кода, выполнение которого при определенных условиях

приводит к ожидаемому поведению системы

Вариант2= участок программного кода, выполнение которого при определенных условиях

приводит к неожиданному поведению системы

41.В задачи тестирования

Вариант1= не входит выявление конкретных дефектных участков программного кода

Вариант2= входит выявление конкретных дефектных участков программного кода

Вариант3= входит исправление дефектов

Вариант4= не входит выявление конкретных дефектных участков программного кода, но

входит исправление дефектов

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

Вариант1= оптимизация количества дефектов в конечном продукте

Вариант2= минимизация количества дефектов в конечном продукте.

Вариант3= декомпозиция количества дефектов в конечном продукте

43. Метод функциональной декомпозиции состоит в том, что

Вариант1= система разбивается на отдельные модули– выполняется модульное тестирование,

затем выполняется интеграционное тестирование и после этого выполняется системное

тестирование.

Вариант2= система разбивается на отдельные модули– выполняется модульное тестирование,

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

Вариант3= система разбивается на отдельные модули– выполняется модульное тестирование,

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

Вариант4= система разбивается на отдельные модули– выполняется модульное тестирование,

затем выполняется системное тестирование и после этого выполняется интеграционное

тестирование.

44.Робастность системы

Вариант1= управляемое выполнение программы с целью обнаружения несоответствий ее

поведения и требований

Вариант2= включает в себя инспекции, тестирование кода, анализ результатов тестирования,

формирование и анализ отчетов о проблемах

Вариант3= проверка соответствия системы ожиданиям заказчика

Вариант4= это степень ее чувствительности к факторам, не учтенным на этапах ее

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

45.Разбиение на классы эквивалентности

Вариант1= способ увеличения необходимого числа тестовых примеров.

Вариант2= способ уменьшения необходимого числа тестовых примеров.

46.Если различные входные значения приводят к одним и тем же реакциям системы

Вариант1= то невозможно объединение таких значений в классы эквивалентности

Вариант2= то возможно объединение таких значений в классы эквивалентности

47.Разбиение на классы эквивалентности особенно полезно

13

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

значений

Вариант2= когда на вход системы может быть подано малое количество различных значений

Вариант3= когда на вход системы не может быть подано большое количество различных

значений

48.Тест-план представляет собой

Вариант1= документ, в котором перечислены часть тестовых примеров, необходимых для

тестирования системы

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

тестирования системы

49.В каждом тестовом примере обязательно перечислены

Вариант1= все входные значения а также сценарий, описывающий последовательность

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

примера

Вариант2= все входные значения и ожидаемые выходные значения, а также сценарий,

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

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

Вариант3= все входные значения и ожидаемые выходные значения

50.Тест считается пройденным

Вариант1= если ожидаемые и реальные выходные значения совпадают

Вариант2= если ожидаемые и реальные выходные значения не совпадают

Вариант3= если система выдала выходные значения, которые не ожидались

51.Одна из оценок качества системы тестов - это ее полнота, т.е.

Вариант1= величина той части функциональности системы, которая не проверяется тестовыми

примерами

Вариант2= величина той части функциональности системы, которая проверяется тестовыми

примерами

52.Покрытие требований позволяет оценить

Вариант1= полноту по отношению к программной реализации системы

Вариант2= степень полноты системы тестов по отношению к функциональности системы

Вариант3= каждая компонента логического условия в результате выполнения тестовых

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

53.Уровни покрытия. По строкам программного кода (Statement Coverage)

Вариант1= в результате выполнения тестов каждый оператор был выполнен хотя бы один раз

Вариант2= для обеспечения полного покрытия необходимо, чтобы как логическое условие,

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

Вариант3= каждая компонента логического условия в результате выполнения тестовых

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

Вариант4= метод учитывающий структуру компонент условий и значения, которые они

принимают при выполнении тестовых примеров

54.Уровни покрытия. По веткам условных операторов (Decision Coverage)

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

принимают при выполнении тестовых примеров

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

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

принять каждое из возможных значений хотя бы один раз

Вариант3= должны быть проверены все возможные наборы значений компонент логических

условий

Вариант4= в результате выполнения тестов каждый оператор был выполнен хотя бы один раз

55.Уровни покрытия. По компонентам логических условий

Вариант1= в результате выполнения тестов каждый оператор был выполнен хотя бы один раз

Вариант2= метод учитывающий структуру компонент условий и значения, которые они

принимают при выполнении тестовых примеров

14

Вариант3= должны быть проверены все возможные наборы значений компонент логических

условий

Вариант4= каждая компонента логического условия в результате выполнения тестовых

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

56.Уровни покрытия. Покрытие по условиям (Condition Coverage)

Вариант1= каждая компонента логического условия в результате выполнения тестовых

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

Вариант2= в результате выполнения тестов каждый оператор был выполнен хотя бы один раз

Вариант3= должны быть проверены все возможные наборы значений компонент логических

условий

Вариант4= для обеспечения полного покрытия необходимо, чтобы как логическое условие,

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

57.Уровни покрытия. Покрытие по веткам/условиям (Condition/Decision Coverage)

Вариант1= для обеспечения полного покрытия необходимо, чтобы как логическое условие,

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

Вариант2= должны быть проверены все возможные наборы значений компонент логических

условий

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

принимают при выполнении тестовых примеров

Вариант4= в результате выполнения тестов каждый оператор был выполнен хотя бы один раз

58.Уровни покрытия. Покрытие по всем условиям (Multiple Condition Coverage)

Вариант1= в результате выполнения тестов каждый оператор был выполнен хотя бы один раз

Вариант2= должны быть проверены все возможные наборы значений компонент логических

условий

Вариант3= для обеспечения полного покрытия необходимо, чтобы как логическое условие,

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

Вариант4= метод учитывающий структуру компонент условий и значения, которые они

принимают при выполнении тестовых примеров

Критерии оценки:

85% и более правильных ответов — оценка «отлично»

от 70 до 85% правильных ответов — оценка «хорошо»

от 50 до 70% правильных ответов — оценка «удовлетворительно»

до 50% правильных ответов — оценка «неудовлетворительно»

КОМПЛЕКТ МАТЕРИАЛОВ ДЛЯ ПРОМЕЖУТОЧНОЙ АТТЕСТАЦИИ

Теоретические вопросы

1.

Модель. Моделирование. Информационная модель.

2.

Классификация методов моделирования.

3.

Концептуальное моделирование

4.

Имитационное моделирование

5.

Методы построения информационных систем. Метод “снизу-вверх”

6.

Методы построения информационных систем. Метод “сверху-вниз”

7.

Методы построения информационных систем. Принципы “дуализма” и

многокомпонентности

8.

Методы построения информационных систем. Каскадная модель.

9.

Методы построения информационных систем. Спиральная модель.

10. Автоматизированная система моделирования (АСМ)

11. Объектно-ориентированный подход проектирования ИС.

12. Цели и задачи моделирования ПО.

15

13. Модели при визуальном моделировании ПО

14. Граф модели и диаграммы

15. Ролевой состав коллектива разработчиков. Заказчик (заявитель).

16. Ролевой состав коллектива разработчиков. Менеджер проекта

17. Ролевой состав коллектива разработчиков. Менеджер программы

18. Ролевой состав коллектива разработчиков. Разработчик

19. Ролевой состав коллектива разработчиков. Специалист по тестированию

20. Ролевой состав коллектива разработчиков. Специалист по контролю качества

21. Ролевой состав коллектива разработчиков. Специалист по сертификации

22. Ролевой состав коллектива разработчиков. Специалист по внедрению и

сопровождению

23. Ролевой состав коллектива разработчиков. Специалист по безопасности

24. Ролевой состав коллектива разработчиков. Инструктор

25. Ролевой состав коллектива разработчиков. Технический писатель

26. Тестирование программного обеспечения

27. Верификация программного обеспечения

28. Валидация программной системы

29. Модульное тестирование

30. Интеграционное тестирование

31. Системное тестирование

32. Верификация сертифицируемого программного обеспечения

33. Задачи и цели тестирования программного кода

34. Методы тестирования. Черный ящик.

35. Методы тестирования. Стеклянный (белый) ящик

36. Методы тестирования. Тестирование моделей

37. Методы тестирования. Анализ программного кода (инспекции)

38. Тестовое окружение. Драйверы и заглушки

39. Тестовое окружение. Тестовые классы

40. Тестовое окружение. Генераторы сигналов (событийно-управляемый код)

41. Типы тестовых примеров. Допустимые данные.

42. Типы тестовых примеров. Граничные данные

43. Типы тестовых примеров. Отсутствие данных

44. Типы тестовых примеров. Повторный ввод данных

45. Типы тестовых примеров. Неверные данные

46. Типы тестовых примеров. Реинициализация системы

47. Типы тестовых примеров. Устойчивость системы.

48. Типы тестовых примеров. Нештатные состояния среды выполнения

49. Типы тестовых примеров. Граничные условия.

50. Тестовые примеры. Проверка робастности (выхода за границы диапазона)

51. Тестовые примеры Классы эквивалентности.

52. Тестовые примеры. Тестирование операций сравнения чисел

53. Типовая структура тест-плана

54. Оценка качества тестируемого кода – статистика выполнения тестов.

55. Покрытие программного кода. Понятие покрытия

56. Покрытие программного кода. Уровни покрытия. По строкам программного кода

(Statement Coverage)

57. Покрытие программного кода. Уровни покрытия. По веткам условных операторов

(Decision Coverage)

58. Покрытие программного кода. Уровни покрытия. Покрытие по условиям (Condition

Coverage)

59. Покрытие программного кода. Уровни покрытия. Покрытие по веткам/условиям

(Condition/Decision Coverage)

16

60. Покрытие программного кода. Уровни покрытия. Покрытие по всем условиям (Multiple

Condition Coverage)

61. Покрытие программного кода. Анализ покрытия.

62. Задачи и цели обеспечения повторяемости тестирования.

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

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

64. Зависимость между тестовыми примерами, настройки по умолчанию для тестовых

примеров и их групп

Перечень теоретических вопросов к дифференцированному зачету (экзамену)

1. Цели, задачи, этапы и объекты моделирования и ревьюирования.

2. Графические языки спецификаций.

3. Основные элементы языка UML.

4. Цели, корректность и направления анализа программных продуктов.

5. Методики оценки программных продуктов.

6. Цели, задачи и методы исследования программного кода.

7. Механизмы и контроль внесения изменений в код.

8. Обратное проектирование.

9. Анализ потоков данных. Диаграмма потоков данных.

10.Валидация кода на стороне сервера и разработчика.

11. Совместимость и использование инструментов ревьюирования в различных системах

контроля версий.

12.Особенности ревьюирования в Linux. Настройки доступа.

13.Типовые инструменты и методы анализа программных проектов.

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

15.Корректность программ. Эталоны и методы проверки корректности.

16.Метрики, направления применения метрик. Метрики сложности. Метрики стилистики.

17.Исследование программного кода на предмет ошибок и отклонения от алгоритма.

18.Основные понятия управления проектами. Специфика управления проектами в сфере IT.

19.Методологии анализа и управления информационных систем.

20.Общая характеристика проектов внедрения ИТ-решений.

21.Определение ЖЦ продукта ИТ-проекта. Обзор моделей жизненного цикла. Обоснование и

приоретизация проекта.

22.Устав проекта.

23.Границы проекта.

24.Реестр заинтересованных лиц.

25.Матрица ожиданий и требований. Балансировка требований.

26.Содержание проекта.

27.Обзор ПО для управления проектами.

28.Иерархическая структура работ. Методы формирования списка работ.

29.Планирование ресурсов. Виды ресурсов.

30.Методы определения продолжительности проекта.

31.Планирование стоимости проекта. Методы расчета стоимости проекта.

32.Расписание проекта. Сетевой анализ расписания проекта.

33.Распределение ответственности. Матрица ответственности. Закрепление функций и

полномочий в проекте.

34.Календарно-ресурсный план.

35.План обеспечения проекта персоналом.

36.Планирование коммуникаций в проекте.

37.План управления качеством.

38.Риски, виды рисков проекта. Реестр рисков.

39.Качественный анализ рисков.

17

40.Количественный анализ рисков.

41.Планирование реагирования на риски.

42.Управление исполнением проекта. Отслеживание выполнения работ. Управление

требованиями.

43.Выявление потребностей пользователей. Мотивирование и развитие команды. 44.Закрытие

проекта.

Перечень практических заданий к дифференцированному зачету (экзамену)

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

2. Определить заинтересованных лиц проекта.

3. Составить матрицу ответственности.

4. Определить список необходимых для выполнения проекта трудовых и материальных

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

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

определить типы задач.

5. В рамках предполагаемого времени проведения проекта определить календарь рабочего

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

и переносы рабочих дней.

6. Определить состав работ: фазы, задачи, вехи; приблизительные длительности задач, типы

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

известна, но лишь приблизительно и впоследствии может быть изменена. Определить

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

7. Определить ставки трудовых ресурсов и порядок оплаты работ, определить стоимость

материальных ресурсов, учесть штрафы за выполнение работ не в срок. Учесть оклады

штатных сотрудников и премии по окончании работ. Определить итоговую стоимость

проекта. Ввести информацию о бюджете, сравнить с оценочными данными.

8. Выровнять загрузку тех сотрудников, кто не согласился работать сверхурочно. Учесть в

стоимости проекта сверхурочную занятость сотрудников. Изменить план проекта в связи с

переносами сроков окончания проекта. Оптимизировать стоимость проекта в связи с

уменьшением бюджета.

9. Рассчитать длительность и вероятность завершения в заданный срок проекта, заданного

сетевым графиком и имеющего известные параметры работ.

10.Управление стоимостью проекта. NASA заказало самарскому СНТК Кузнецова

изготовление двигателей для ракеты-носителя «Атлантис». Оценить значения показателей CV,

SV, CPI, SPI на момент окончания проекта по методу освоенного объема. Известны плановые

и фактические показатели проекта.

11. Рассчитать показатели NPV, PI и РР проекта длительностью 6 лет, если известны ставка

дисконтирования, инвестиции, расходы и доходы. Рассчитать длительность проекта.

12.Определить вероятность завершения проекта в заданный срок.

13.Исследовать влияние неопределенности длительности работ на вероятность завершения

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

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

сетевой график и желаемый срок завершения проекта.

Деловая игра

по междисциплинарному курсу 03.01 «Моделирование и анализ программного

обеспечения»

Тема: «Ревьюирование предложенного программного кода на соответствие требованиям

технического задания на проект».

Концепция игры. Участники игры получают от преподавателя персональный программный

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

построить модель программного кода, определить его характеристики, провести анализ

18

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

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

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

по максимальному объему выполненных анализа и оптимизации.

Роли:

• тестировщик — производит анализ и оптимизацию программного кода;

• эксперты — оценивают анализ и проведенную оптимизацию.

Ожидаемый результат:

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

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

Критерии оценки:

Оценка 5 «отлично»: участник справился с ролью без недочетов и ошибок.

Оценка 4 «хорошо»: участник справился с ролью с некоторыми недочетами, не повлиявшими

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

Оценка 3 «удовлетворительно»: участник справился с ролью с ошибками, повлиявшими на

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

Оценка 2 «неудовлетворительно»: участник не справился с ролью.

Деловая игра

по междисциплинарному курсу 03.02 «Управление проектами»

Тема: «Зависимость финансового результата от качества сделанной работы».

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

предыдущих

практических

занятий.

Каждый

обучающийся

должен

самостоятельно

определить методы анализа и оптимизации проекта и реализовать их на практике.

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

участниками игры, выступающими в роли инвесторов. Победители определяются по

максимальному объему сделанных инвестиций.

Роли:

• разработчик проекта — производит анализ и оптимизацию проекта;

• инвестор — оценивает проект и делает инвестиции, в случае положительной оценки.

Ожидаемый результат:

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

сделанной работы.

Критерии оценки:

Оценка 5 «отлично» — более 75% инвесторов сделали вложения в проект.

Оценка 4 «хорошо» — от 50 до 75% инвесторов сделали вложения в проект.

Оценка 3 «удовлетворительно» — от 25 до 50% инвесторов сделали вложения в проект.

Оценка 2 «неудовлетворительно» — менее 25% инвесторов сделали вложения в проект.

Деловая игра

по междисциплинарному курсу 03.02 «Управление проектами»

Тема:

«Анализ рисков. Необходимость учета эстетического фактора при применении

информационной».

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

предыдущих

практических

занятий.

Каждый

обучающийся

должен

самостоятельно

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

реакции на риски.

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

участниками игры, выступающими в роли инвесторов. Победители определяются по

максимальному объему сделанных инвестиций.

Роли:

19

• разработчик проекта — производит анализ рисков и оптимизацию проекта, с учетом

проведенного анализа;

• инвестор — оценивает проект и делает инвестиции, в случае положительной оценки.

Ожидаемый результат:

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

сделанной работы.

Критерии оценки:

Оценка 5 «отлично» — более 75% инвесторов сделали вложения в проект.

Оценка 4 «хорошо» — от 50 до 75% инвесторов сделали вложения в проект.

Оценка 3 «удовлетворительно» — от 25 до 50% инвесторов сделали вложения в проект.

Оценка 2 «неудовлетворительно» — менее 25% инвесторов сделали вложения в проект.

Деловая игра

по междисциплинарному курсу 03.02 «Управление проектами»

Тема: «Создание физического дизайна. Зависимость результата от командных условий».

Концепция игры.

Участники игры делятся на две проектные команды и распределяют между собой роли (см.

ниже). Каждая команда получает от преподавателя проект. В ходе игры, участники за

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

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

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

Роли:

•

менеджер

решения:

управление

ожиданиями

пользователей

и

создание

плана

взаимодействия, подготовка к развертыванию решения;

•

менеджер

программы:

управление

процессом

физического

дизайна

и

создание

функциональной спецификации;

• разработчик: представление проектных моделей, планов, календарных графиков и смет

разработки;

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

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

• тестировщик: оценка и проверка функционального наполнения и целостности физического

дизайна на основании СИС;

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

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

из ее участников.

Критерии оценки:

Оценка 5 «отлично»: участник справился с ролью без недочетов и ошибок.

Оценка 4 «хорошо»: участник справился с ролью с некоторыми недочетами, не повлиявшими

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

Оценка 3 «удовлетворительно»: участник справился с ролью с ошибками, повлиявшими на

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

Оценка 2 «неудовлетворительно»: участник не справился с ролью.

20