Файл: Программа ИВТм-11-2013для магистров.doc

№ п\п	№ раздела дисциплины	Наименование практической работы	Трудоёмкость (час.)
1	2	Решение задач в методологии объектно-ориентированнного программирования.	8
2	3	Разработка структуры приложения Windows.	8
3	4	Разработка интерфейса пользователя.	3
Итого:			19

9. Учебно-методическое обеспечение

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

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

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

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

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

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

- текущий контроль (аудиторная контрольная работа- тесты)

-промежуточный контроль (зачет)

- итоговый контроль.(экзамен)

Аттестационный балл семестра складывается из баллов текущей «аттестации» в середине семестра (10) и баллов второй половины семестра «работа в семестре» (10), каждый из которых учитывает успешность работы студента в семестре:, аудиторной контрольной работы, активность студента во время аудиторных занятий, выполнение им заданий для самостоятельной работы и результаты собеседований по лекционному материалу и материалу практических заданий.

Оценка за работу в течение семестра (текущий контроль) выставляется по 100-бальной шкале, в соответствии с нормативными документами вуза, и затем конвертируется в 10-бальную оценку следующим образом:

Ниже 51 балла	0 баллов (не аттестовано)
51-55 баллов	1 балл
56-60 баллов	2 балла
61-65 баллов	3 балла
66-70 баллов	4 балла
71-75 баллов	5 баллов
76-80 баллов	6 баллов
81-85 баллов	7 баллов
86-90 баллов	8 баллов
91-95 баллов	9 баллов
96-100 баллов	10 баллов

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

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

Таблица. Соответствие оценок по десятибалльной и пятибалльной системам

По десятибалльной шкале	По пятибалльной шкале
1 – неудовлетворительно 2 – очень плохо 3 – плохо	неудовлетворительно – 2
4 – удовлетворительно 5 – весьма удовлетворительно	удовлетворительно – 3
6 – хорошо 7 – очень хорошо	хорошо – 4
8 – почти отлично 9 – отлично 10 – блестяще	отлично – 5

10. Пример тестовых заданий

1 вариант

1) Выберите правильные утверждения:

А) Жизненный цикл проекта – это набор последовательных фаз проекта (лекция)

Б) (абсолютность спорна)

В) (опять же абсолютность спорна)

Г) В классической водопадной модели жизненного цикла ПО этак проектирования строго предшествует этапу кодирования (лекция)

2) Какие из перечисленных моделей ЖЦП относятся к эволюционным моделям разработки ПО?

А) каскадная модель – не относится

Б) Модель пробных разработок – точно относится

В) Прототипирование – точно относится

Г) Модель пошаговой разработки – не относится

Д) Спиральная модель – относится согласно Орлову

Согласно http://se.math.spbu.ru/seminars/se1/SE_4.htm#_1._Модели_процесса :

3) Расположите в хронологическом порядке этапы процесса проектирования:

А) Проектирование интерфейсов

Б) Архитектурное проектирования

В) Обобщённая спецификация

Г) Проектирование алгоритмов

Д) Компонентное проектирование

Е) Проектирование структур данных

Б – В – А – Д – Е – Г, согласно, http://se.math.spbu.ru/seminars/se1/SE_4.htm#_4._Проектирование_и :

4) Расположите в хронологическом порядке этапы процесса тестирования:

А) Тестирование компонентов

Б) Тестирование подсистем

В) Тестирование модулей

Г) Тестирование системы

Д) Приёмочные испытания

А – В – Б – Г – Д, согласно http://se.math.spbu.ru/seminars/se1/SE_4.htm#_5._Аттестация_программных :

5) Какие работы не должен выполнять менеджер проекта по разработке программного обеспечения?

А) Написание предложений по созданию ПО – менеджер тоже выполняет подобные работы

Б) Планирование и составление графика работ по созданию ПО

В) Тестирование модулей – для этого существует тестер

Г) Оценка стоимости проекта – должен выполнять менеджер

Д) Подбор персонала – отчасти выполняет менеджер

Е) Разработка требований к ПО – это дело разработчиков, заказчиков и пользователей, а менеджер только направляет

Вот то, что должен делать менеджер (взято с http://se.math.spbu.ru/seminars/se1/SE_3.htm#1 ):

6) Какие работы находятся в исключительной ответственности менеджера проекта?

А) Контроль выполнения проекта

Б) Контроль соответствия проекта требованиям заказчика

В) Обеспечение своевременного поступления средств

Г) Информирование заказчика о важных событиях проекта

Видимо, за всё перечисленное ответственен менеджер.

7) Каким понятиям соответствуют приведённые определения?

Понятие	Определение
1. Жизненный цикл программы	А) Деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, денежным средствам и ресурсам, а также качеству конечных результатов проекта
2. Управление проектом	Б) Совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные
3. Процесс	В) Весь период разработки и эксплуатации программы, начиная с момента возникновения замысла и заканчивая прекращением всех видов её использования
4. Этап (стадия)	Г) Одномоментное идентифицируемое событие, сопровождающееся появлением и фиксацией некоторого отчуждаемого материала (документа, программы, протокола)
5. Контрольная отметка работ	Д) Часть процесса работы над проектом, которая характеризуется вехой, достижение которой знаменует завершение этой части процесса

1  В (интуитивно понятно)

2  А (классическое определение, см. в “Управление программными проектами” Фатрелл Р., Шафер Д, Шафер Л.)

3  Б (определение с лекции от 14.02.07)

4  Д (определение с лекции от 14.02.07)

5  Г (определение с лекции от 14.02.07) [Контрольная отметка работ – это то же самое, что веха]

8) Определите типы возможных рисков программных проектов:

Описание риска	Тип риска
1. Текучесть разработчиков: опытные разработчики покидают проект до его завершения	А) Риск для проекта
2. Изменение требований: появление большого количества непредвиденных изменений в требованиях, предъявляемых к разрабатываемому ПО	Б) Риск для проекта и разрабатываемого продукта
3. Недооценка размера разрабатываемой системы: CASE-средства, предназначенные для поддержки проекта, оказались менее эффективными, чем ожидалось	В) Риски для разрабатываемого продукта

Про риски можно почитать здесь: http://www.integrate.ru/tech/risks.html

1  А

2  Б

3  В

То, что нам нужно (взято с http://se.math.spbu.ru/seminars/se1/SE_3.htm#4 ):

9) Каким рискам соответствуют приведённые стратегии его уменьшения?

Причины риска	Методы уменьшения риска
1. Финансовые проблемы организации	А) Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы
2. Проблемы неквалифицированного персонала	Б) Попытаться определить требования, наиболее подверженные изменениям; в структуре системы не отображать детальную информацию
3. Изменение требований	В) Рассмотреть возможность покупки более производительной базы данных
4. Недостаточная производительность базы данных	Г) Подготовить краткий документ для руководства организации, показывающий важность данного проекта для достижения финансовых целей организации