Информация об изменениях

Сообщение Re: Курсовые - как это делается в Астраханском универе от 24.01.2019 4:56

Изменено 24.01.2019 4:58 LaptevVV

Re: Курсовые - как это делается в Астраханском универе
Министерство спит и видит, чтоб совсем нас под корень извести.
Но не на тех напали!
Несмотря на ЕГЭ, несмотря на катастрофическое урезание аудиторной нагрузки, несмотря ни на что, мы таки выпускаем ГОТОВЫХ спецов.
Ибо приходят в конторы и сразу работают, а не обучаются работать.
Кто не может научиться работать во время учебы — просто вылетают.
Поэтому сейчас у нас выпуски обычно НЕ БОЛЕЕ 10 человек.

Насчет курсовых.
Теперь у нас по 2 (ДВЕ) курсовых в семестре — для программных инженеров.
Кроме 1 семестра — там 1 (одна).
Тут в форуме С++ был пост про руссификацию FLTK — наши пацаны сделали.
На 3 курсе практически все уже на гитхабе сидят

Только мои курсовые — по дисциплинам:
а) Алгоритмы и структуры данных — 3 семестр
б) Архитектура ВС — 3 семестр
в) Учебная практика — 3 семестр
г) ООП — 4 семестр
д) Распределенная учебная практика — 5 семестр
е) Учебная практика 5 семестр
В 4 семестре параллельно с моей курсовой — еще по другой дисциплине есть
В 5 семестре — Коллективный проект. И еще какая-то курсовая
Коллективный проект — это уже реально работа в команде под руководством тимлида (выбирается из команды)
и начальник есть — преподаватель.
Он раздает темы, назначает сборища (1 раз в неделю или 2 раза в неделю), на которых
а) проверяется выполненная работа
б) определяется конкретная работа до следующего сборища.
Вся работа делается на гитхабе.
Но док в конце — это "святое".
Ибо аккредитация (только что была в октябре) — там эксперты проверяют только документацию.
Не будет какого-нить дока — мало не покажется.
Вплоть до закрытия специальности.
Потому — обязательно.

Тут народ по темам прохаживался...
Ну вот, например, как формулируется задание по обучающей системе:

Общие требования
1. Учебно-демонстрационная программа (УДП) состоит из 3 подсистем:
1. Подсистема просмотра учебного материала
2. Подсистема демонстрации алгоритмов и операций
3. подсистема проверки знаний (тестирование)

2. Система должна обеспечивать расширение (дополнение) каждой из подсистем без существенной модификации уже реализованного функционала.
3. Функциональный код должен быть реализован на языке С++14 (и выше) в объектно – ориентированном стиле с использованием стандартной библиотеки STL.

4. Интерфейс должен быть реализован на С++ с помощью одной из библиотек:
1. Qt
2. wxWidget
3. FLTK
4. Ultimate++
По согласованию с заказчиком могут быть использованы любые другие свободно распространяемые библиотеки C++ .
По согласованию с заказчиком может быть использована библиотека Sciter или аналогичные библиотеки, реализованные на JS.

5. Интерфейсная часть системы не должна содержать функциональный код.
6. Система должна предоставлять интерактивную помощь по работе с ней.
7. Система должна работать под управление ОС Windows XP и выше, ОС Linux (AltLinux 7)
8. Должен быть создан инсталляционный пакет с использованием любого свободно распространяемого инсталлятора.

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

2. Теоретический материал может включать:
a. Текст
b. Коды программы
c. Таблицы
d. Рисунки

3. Теоретический материал должен быть организован в виде гипертекста с разбиением на подразделы и страницы.
4. Должно быть обеспечено общее содержание. В содержании указываются подразделы теоретического материала (НЕ СТРАНИЦЫ).

5. Для каждой страницы должен быть обеспечен переход:
a. К следующей странице
b. К предыдущей странице
c. В начало подраздела
d. К общему содержанию.

6. Все определения, прописанные в теоретическом материале, должны быть собраны в отдельный словарь и в тексте теоретического материала снабжены гиперссылками.
7. Подсистема должна обеспечивать подключение новой порции теоретического материала без изменения программного кода.

Подсистема демонстрации алгоритмов и операций
1. Подсистема должна демонстрировать на экране выполнение всех операций и алгоритмов, относящихся к теме.
2. Каждый алгоритм должен демонстрироваться пошагово.
3. Подсистема должна обеспечивать пошаговый переход вперед и назад. Должна быть обеспечена возможность начать с первого шага, и выполнить без пошаговой демонстрации.
4. При демонстрации алгоритмов и операций должен быть доступен теоретический материал по соответствующему подразделу.

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

2. Подсистема должна обрабатывать два типа вопросов:
a. Выбор нескольких ответов из нескольких альтернатив; количество альтернатив от 5 до 9;
b. Открытый вопрос;
3. В текст вопроса может входить код программы.

4. Каждый вопрос характеризуется следующими атрибутами:
a. Тема к которой он относится (один вопрос может относится к нескольким темам)
b. Сложность вопроса – минимальная, базовая, повышенная
c.

5. Вопросы должны быть записаны в текстовых файлах в зашифрованном виде. Система должна предоставлять пользователю возможность зашифровать и расшифровать файл с вопросами (допускается реализовать консольный вариант).
6. Подсистема должна обеспечивать возможность подключения новых файлов с вопросами.
7. Формат файла вопросов должен быть простой и подготовка его должна выполняться в простом текстовом редакторе типа Блокнот. Пользователю должна быть предоставлена инструкция по формированию файла вопросов. Формат файла вопросов должен быть описан в пояснительной записке.

8. По согласованию с заказчиком подсистема должна обеспечивать настройки:
a. Количество вопросов, выбираемых для создания теста.
b. Список тем, из которых будут выбираться вопросы для тестирования.
c. Максимальный уровень сложности вопросов, включаемых в тест.
d. Время проведения теста
e. Способ окончания тестирования:
i. Все вопросы отвечены.
ii. Закончилось время тестирования.
iii. Сделано k ошибок в ответах
iv. Доля неверных ответов превзошла D: 0 < D < 1.
f. Контрольный/обучающий режим

9. В обучающем режиме должен быть доступен теоретический материал из соответствующего подраздела (темы). В контрольном режиме теоретический материал должен быть недоступен.

10. По согласованию с заказчиком должна быть разработана система оценивания
a. отдельного вопроса, которая учитывает сложность вопроса
b. всего теста

11. Информация о результатах тестирования должна сохраняться в текстовых файлах. Формат сохраняемого файла должен быть разработан и описан в пояснительной записке.
12. В обучающем режиме система по запросу пользователя должна предоставлять информацию об ответах на тест.

Ну, и по Архитектуре:

Виртуальные машины.

Требования к реализации
0. Реализовать интерпретатор как консольное приложение.
1. Объектно-ориентированный подход.
1.1 Процессор – отдельный класс, разделение на интерфейс и реализацию;
Выполнение команд – вызов функтора (не использовать оператор-переключатель!)
Память – динамический массив, поле-указатель в классе.
1.2 Команды процессора – иерархия классов-функторов; базовый класс – абстрактный класс Command с перегруженной операцией operator()

2. Разработать и описать в пояснительной записке:
– коды команд
– методы адресации операндов
– множество флагов-результатов
– форматы команд переходов (если не определены)

Обязательно должны быть реализованы команды:
2.1 Пересылки (по необходимости)
2.2 Арифметика (целые и дробные)
2.3 Сравнения (целые и дробные)
2.3 Ввод-вывод (целые и дробные)
2.4 Переходы
– безусловный
– условный
– к подпрограмме
– возврат из подпрограммы

3. Загрузчик программы для виртуальной машины – независимая функция, вызываемая главной программой интерпретатора..
3.1 Код программы для виртуальной машины должен быть записан в текстовом файле.
3.2 Формат представления кода программы в файле должен быть разработан и описан в пояснительной записке.
3.3 Загрузчик должен быть способен загружать код программы по любому адресу памяти
3.3 Главная программа должна получать имя файла как параметр командной строки, и передавать загрузчику как параметр при вызове.

И пример архитектуры:

10. Смешанная, два операнда в регистрах, один – в памяти
Память: слова – 32 бита, размер адреса – 16 бит
PSW = IP + Flags, 16 + 16 = 32 бита
Типы данных:
Целые знаковые, беззнаковые – 4 байта
Дробные – 4 байт
РОН – 16 штуки, 32 бита – целые
Они же, 32 бита – дробные

Структура команды: 16 бит (2 команды в слове), 32 бита
16 бит : КОП – 8 бит, r1 – 4 бит, r2 – 4 бит
32 бита: КОП – 8 бит, r1 – 4 бит, r2 – 4 бит, адрес (константа) – 16 бит
Результат – в r2.
Пересылка регистр-регистр
Пересылка память-регистр, регистр-память
Загрузка константы-адреса в регистр
Арифметика целая – двухадресная и трехадресная
Арифметика дробная – двухадресная и трехадресная
Переходы:
Безусловный:
– прямой
– относительный
– косвенный прямой
Условный – то самое, только с проверкой флагов
К подпрограмме – адрес возврата в r2
Возврат из подпрограммы

Re: Курсовые - как это делается в Астраханском универе
Министерство спит и видит, чтоб совсем нас под корень извести.
Но не на тех напали!
Несмотря на ЕГЭ, несмотря на катастрофическое урезание аудиторной нагрузки, несмотря ни на что, мы таки выпускаем ГОТОВЫХ спецов.
Ибо приходят в конторы и сразу работают, а не обучаются работать.
Кто не может научиться работать во время учебы — просто вылетают.
Поэтому сейчас у нас выпуски обычно НЕ БОЛЕЕ 10 человек.

Насчет курсовых.
Теперь у нас по 2 (ДВЕ) курсовых в семестре — для программных инженеров.
Кроме 1 семестра — там 1 (одна).
Тут в форуме С++ был пост про руссификацию FLTK — наши пацаны сделали.
На 3 курсе практически все уже на гитхабе сидят

Только мои курсовые — по дисциплинам:
а) Алгоритмы и структуры данных — 3 семестр
б) Архитектура ВС — 3 семестр
в) Учебная практика — 3 семестр
г) ООП — 4 семестр
д) Распределенная учебная практика — 5 семестр
е) Учебная практика 5 семестр
В 4 семестре параллельно с моей курсовой — еще по другой дисциплине есть
В 5 семестре — Коллективный проект. И еще какая-то курсовая
Коллективный проект — это уже реально работа в команде под руководством тимлида (выбирается из команды)
и начальник есть — преподаватель.
Он раздает темы, назначает сборища (1 раз в неделю или 1 раз в 2 недели), на которых
а) проверяется выполненная работа
б) определяется конкретная работа до следующего сборища.
Вся работа делается на гитхабе.
Но док в конце — это "святое".
Ибо аккредитация (только что была в октябре) — там эксперты проверяют только документацию.
Не будет какого-нить дока — мало не покажется.
Вплоть до закрытия специальности.
Потому — обязательно.

Тут народ по темам прохаживался...
Ну вот, например, как формулируется задание по обучающей системе:

Общие требования
1. Учебно-демонстрационная программа (УДП) состоит из 3 подсистем:
1. Подсистема просмотра учебного материала
2. Подсистема демонстрации алгоритмов и операций
3. подсистема проверки знаний (тестирование)

2. Система должна обеспечивать расширение (дополнение) каждой из подсистем без существенной модификации уже реализованного функционала.
3. Функциональный код должен быть реализован на языке С++14 (и выше) в объектно – ориентированном стиле с использованием стандартной библиотеки STL.

4. Интерфейс должен быть реализован на С++ с помощью одной из библиотек:
1. Qt
2. wxWidget
3. FLTK
4. Ultimate++
По согласованию с заказчиком могут быть использованы любые другие свободно распространяемые библиотеки C++ .
По согласованию с заказчиком может быть использована библиотека Sciter или аналогичные библиотеки, реализованные на JS.

5. Интерфейсная часть системы не должна содержать функциональный код.
6. Система должна предоставлять интерактивную помощь по работе с ней.
7. Система должна работать под управление ОС Windows XP и выше, ОС Linux (AltLinux 7)
8. Должен быть создан инсталляционный пакет с использованием любого свободно распространяемого инсталлятора.

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

2. Теоретический материал может включать:
a. Текст
b. Коды программы
c. Таблицы
d. Рисунки

3. Теоретический материал должен быть организован в виде гипертекста с разбиением на подразделы и страницы.
4. Должно быть обеспечено общее содержание. В содержании указываются подразделы теоретического материала (НЕ СТРАНИЦЫ).

5. Для каждой страницы должен быть обеспечен переход:
a. К следующей странице
b. К предыдущей странице
c. В начало подраздела
d. К общему содержанию.

6. Все определения, прописанные в теоретическом материале, должны быть собраны в отдельный словарь и в тексте теоретического материала снабжены гиперссылками.
7. Подсистема должна обеспечивать подключение новой порции теоретического материала без изменения программного кода.

Подсистема демонстрации алгоритмов и операций
1. Подсистема должна демонстрировать на экране выполнение всех операций и алгоритмов, относящихся к теме.
2. Каждый алгоритм должен демонстрироваться пошагово.
3. Подсистема должна обеспечивать пошаговый переход вперед и назад. Должна быть обеспечена возможность начать с первого шага, и выполнить без пошаговой демонстрации.
4. При демонстрации алгоритмов и операций должен быть доступен теоретический материал по соответствующему подразделу.

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

2. Подсистема должна обрабатывать два типа вопросов:
a. Выбор нескольких ответов из нескольких альтернатив; количество альтернатив от 5 до 9;
b. Открытый вопрос;
3. В текст вопроса может входить код программы.

4. Каждый вопрос характеризуется следующими атрибутами:
a. Тема к которой он относится (один вопрос может относится к нескольким темам)
b. Сложность вопроса – минимальная, базовая, повышенная
c.

5. Вопросы должны быть записаны в текстовых файлах в зашифрованном виде. Система должна предоставлять пользователю возможность зашифровать и расшифровать файл с вопросами (допускается реализовать консольный вариант).
6. Подсистема должна обеспечивать возможность подключения новых файлов с вопросами.
7. Формат файла вопросов должен быть простой и подготовка его должна выполняться в простом текстовом редакторе типа Блокнот. Пользователю должна быть предоставлена инструкция по формированию файла вопросов. Формат файла вопросов должен быть описан в пояснительной записке.

8. По согласованию с заказчиком подсистема должна обеспечивать настройки:
a. Количество вопросов, выбираемых для создания теста.
b. Список тем, из которых будут выбираться вопросы для тестирования.
c. Максимальный уровень сложности вопросов, включаемых в тест.
d. Время проведения теста
e. Способ окончания тестирования:
i. Все вопросы отвечены.
ii. Закончилось время тестирования.
iii. Сделано k ошибок в ответах
iv. Доля неверных ответов превзошла D: 0 < D < 1.
f. Контрольный/обучающий режим

9. В обучающем режиме должен быть доступен теоретический материал из соответствующего подраздела (темы). В контрольном режиме теоретический материал должен быть недоступен.

10. По согласованию с заказчиком должна быть разработана система оценивания
a. отдельного вопроса, которая учитывает сложность вопроса
b. всего теста

11. Информация о результатах тестирования должна сохраняться в текстовых файлах. Формат сохраняемого файла должен быть разработан и описан в пояснительной записке.
12. В обучающем режиме система по запросу пользователя должна предоставлять информацию об ответах на тест.

Ну, и по Архитектуре:

Виртуальные машины.

Требования к реализации
0. Реализовать интерпретатор как консольное приложение.
1. Объектно-ориентированный подход.
1.1 Процессор – отдельный класс, разделение на интерфейс и реализацию;
Выполнение команд – вызов функтора (не использовать оператор-переключатель!)
Память – динамический массив, поле-указатель в классе.
1.2 Команды процессора – иерархия классов-функторов; базовый класс – абстрактный класс Command с перегруженной операцией operator()

2. Разработать и описать в пояснительной записке:
– коды команд
– методы адресации операндов
– множество флагов-результатов
– форматы команд переходов (если не определены)

Обязательно должны быть реализованы команды:
2.1 Пересылки (по необходимости)
2.2 Арифметика (целые и дробные)
2.3 Сравнения (целые и дробные)
2.3 Ввод-вывод (целые и дробные)
2.4 Переходы
– безусловный
– условный
– к подпрограмме
– возврат из подпрограммы

3. Загрузчик программы для виртуальной машины – независимая функция, вызываемая главной программой интерпретатора..
3.1 Код программы для виртуальной машины должен быть записан в текстовом файле.
3.2 Формат представления кода программы в файле должен быть разработан и описан в пояснительной записке.
3.3 Загрузчик должен быть способен загружать код программы по любому адресу памяти
3.3 Главная программа должна получать имя файла как параметр командной строки, и передавать загрузчику как параметр при вызове.

И пример архитектуры:

10. Смешанная, два операнда в регистрах, один – в памяти
Память: слова – 32 бита, размер адреса – 16 бит
PSW = IP + Flags, 16 + 16 = 32 бита
Типы данных:
Целые знаковые, беззнаковые – 4 байта
Дробные – 4 байт
РОН – 16 штуки, 32 бита – целые
Они же, 32 бита – дробные

Структура команды: 16 бит (2 команды в слове), 32 бита
16 бит : КОП – 8 бит, r1 – 4 бит, r2 – 4 бит
32 бита: КОП – 8 бит, r1 – 4 бит, r2 – 4 бит, адрес (константа) – 16 бит
Результат – в r2.
Пересылка регистр-регистр
Пересылка память-регистр, регистр-память
Загрузка константы-адреса в регистр
Арифметика целая – двухадресная и трехадресная
Арифметика дробная – двухадресная и трехадресная
Переходы:
Безусловный:
– прямой
– относительный
– косвенный прямой
Условный – то самое, только с проверкой флагов
К подпрограмме – адрес возврата в r2
Возврат из подпрограммы