План навчально-методичного забезпечення дисципліни

Специфікація навчальних матеріалів: перелік, структура, шаблони. Самі матеріали генеруються з даних курсу — цей документ теж.

Уклав: викладач Ординський О. О. · вересень 2026

1. Призначення документа

Цей документ — специфікація навчально-методичного забезпечення дисципліни «Системне програмування». Він не містить самих матеріалів (конспектів, текстів завдань, питань банку) — він визначає їхній повний перелік, структуру, шаблони та взаємозв'язки, щоб матеріали можна було згенерувати послідовно й узгоджено.

Опорні документи: робоча програма дисципліни (тематичний план, компетентності, критерії) і силабус (політики, оцінювання), обидва в цій самій теці; Положення про навчально-методичне забезпечення ВТФК (структура методичних вказівок, Додаток 4 — теми Google класу, п. 4.8.2 — п'ять рівнів засвоєння).

Ключовий принцип курсу: знайомство і зацікавлення, а не глибина. Лекція = одна ідея + одне живе демо. Лабораторна = один артефакт за 2 години. СРС = добровільна глибина (окремо не оцінюється). Наскрізна лінія — три межі між програмою і машиною: контейнер, перевірка запозичень Rust, набір інструкцій WebAssembly.

1.1. Дві версії практичних матеріалів

Кожна методична вказівка до лабораторної та кожне завдання СРС існують у двох рівнозначних версіях з однаковим технічним змістом і однаковими трьома рівнями завдань:

• Академічна версія — формальні методичні вказівки за структурою Положення про НМЗ. Для звітності, циклової комісії й студентів, які надають перевагу класичному формату.

• Довільна (сюжетна) версія — той самий зміст, вплетений у наскрізну історію про штучний інтелект С.І.Д. Для мотивації й залучення.

Студент виконує будь-яку версію на власний вибір — технічний результат і критерії оцінювання ідентичні. Перемикач між версіями стоїть угорі кожної сторінки сайту.

1.2. Трирівнева модель оцінювання (нагадування)

Рівні монотонні: рівень 2 передбачає виконаний рівень 1, рівень 3 — виконані 1 і 2. Оцінку можна підвищити до закриття відповідного модуля.

2. Загальна карта матеріалів

Повний реєстр артефактів дисципліни. Колонка «Публікація» вказує, де матеріал з'являється для студента (GitHub Pages — відкриті сторінки; Classroom — Google Classroom; репозиторій — закритий репозиторій дисципліни).

Межа публікації, і вона не така, як здавалося. Банк тестових питань не потрапляє у збірку GitHub Pages ніколи (публікуються лише теки з білого списку). А от автогрейдери публічні — і це не недогляд, а властивість Classroom 50: бандл перевірок публікується на Pages, щоб його могли завантажити runner'и, і читається будь-ким за URL. Тому в автотести не кладеться нічого, чого студент не має бачити; усе, що мусить лишитися закритим, перевіряється на захисті. Так само публічні й репозиторії лабораторних (repo_visibility: public) — у публічному репозиторії GitHub-hosted runner'и безкоштовні.

2.1. Де живуть матеріали і як виглядають

Усі матеріали — вихідні дані в репозиторії github.com/AlexOrd/vtfk-materials (content/sp/): лекції як дані (JSON + markdown-конспект), вказівки до ЛР у двох версіях, СРС, банк питань, конфігурація проведення (offering). Один білдер (site/build.mjs) генерує з них статичний сайт на GitHub Pages — docs.sp.ordynski.com; той самий набір даних читає застосунок курсу через Sync.

Оформлення — єдина дизайн-система (тема «cyberpunk»): лекції — слайд-колоди Reveal.js у ретро-моніторі (неонові cyan/yellow/magenta на майже-чорному, шрифти Orbitron + Chakra Petch). Той самий вигляд — у кабінеті застосунку. Друга дисципліна (ОБД) — тема «magical». Деталі — у docs/guides/Design_System.md.

Кожна сторінка ЛР, СРС і конспекту має блок «Команди на цій сторінці» — кожна команда терміналу одним реченням, зі словника commands.yml; команда, що з'являється в курсі вперше, позначається як нова. Окремою сторінкою збирається довідник «Коли щось пішло не так» — усі типові помилки з усіх лабораторних, із пошуком.

3. Конспекти лекцій

Десять лекцій по 2 години плюс вступне заняття (Лекція 0) поза сіткою годин; розподіл по модулях 6/8/6 год. Кожен конспект — одна ідея й одне живе демо, не перелік технологій.

3.1. Шаблон конспекту лекції

1. Тема і місце в наскрізній лінії (яку з трьох меж торкає).

2. Одна ключова ідея — формулювання в одному реченні.

3. Живе демо — команди/код, які викладач показує наживо; очікуваний вивід.

4. Опорний конспект — текст із визначеннями й схемами; для тем, які студент бачить уперше, окремий блок «перше входження»: що це взагалі й нащо, до того як «як це працює».

5. Зв'язок із ЛР — яка лабораторна спирається на цю лекцію.

6. Джерела — українське першим, англійське з позначкою «EN» і оцінкою часу на читання.

3.2. Перелік лекцій

4. Методичні вказівки до лабораторних робіт

Десять лабораторних по 2 години плюс вступна (Лабораторна 0, без слота в розкладі, не оцінюється, відкрита весь семестр). Кожна — атомарний артефакт із видимим результатом наприкінці пари; кожна має академічну і сюжетну версію (розділ 1.1).

4.1. Шаблон академічної версії

Структура за Положенням про НМЗ (методичні вказівки до лабораторних):

7. Тема і мета роботи.

8. Теоретичні відомості — стислий мінімум, потрібний для виконання (не дублює лекцію того самого дня; блок «Освіжити перед роботою»).

9. Обладнання і програмне забезпечення — контейнер розробника / Codespaces, потрібні утиліти.

10. Порядок виконання — покроково, з очікуваним результатом кожного кроку.

11. Завдання за трьома рівнями — рівень 1 (базовий, оцінка 3), рівень 2 (захист, 4), рівень 3 (розширення, 5). Для рівнів 2–3 умова формулюється у двох рівноцінних версіях: на власному наскрізному артефакті або на референсному знімку.

12. Дві парні теми СРС — одна готує до рівня 2, друга до рівня 3.

13. Контрольні питання до захисту — 5–8 питань.

14. Критерії оцінювання і форма звіту — що здається (тег submit/labNN), що перевіряють автотести, що на захисті.

4.2. Шаблон сюжетної версії

Той самий технічний зміст, подано як завдання від С.І.Д. Структура:

15. Бриф С.І.Д. — уривок історії, який ставить задачу «в лорі».

16. Що це означає технічно — переклад брифу на інженерну мову.

17. Три рівні як ігрові ранги — Першокурсник / Магістр / Легенда Коледжу (= рівні 1/2/3).

18. Розбивка рівня 1 на етапи, щоб сторінка не була суцільною.

19. Блок «Коли щось пішло не так» — типові помилки з відповідями С.І.Д.

20. Критерії й здача — ідентичні академічній версії.

Інваріант: рівні, автотести, критерії й теги здачі в обох версіях однакові. Різниться лише обрамлення. Це гарантує, що студенти двох версій оцінюються за одним стандартом.

4.3. Два репозиторії студента

Рівень 1 кожної лабораторної живе у власному репозиторії роботи sp-<група>-labNN-<логін>, який курс створює на прийняття завдання: там код і REPORT.md, здача — тегом submit/labNN, перевірка — автотестами. Ім'я репозиторію є первинним ключем конвеєра перевірки, тому одна робота = один репозиторій.

Рівні 2 і 3 дають опцію працювати на наскрізному артефакті — власному репозиторії студента vtfk-sid, створеному один раз на першій лабораторній і живому до десятої. Він не перевіряється машиною: рівні 2–3 здаються захистом. Хто наскрізного артефакту не веде, не втрачає нічого — кожна умова рівнів 2–3 має другу версію, «на референсному знімку».

4.4. Зведена таблиця лабораторних

ЛР0 · Вступ: як влаштований курс, робоче середовище в Docker і здача робіт ⟷ «Перше ввімкнення» (Модуль —)

Парні теми СРС: немає — вступна робота, поза сіткою годин.

ЛР1 · Контейнер розробника: перша капсула ⟷ «Ізоляційна Капсула» (Модуль 1)

Парні теми СРС: (рів. 2) Публікація портів у Docker: -p, EXPOSE і чому без них хост не бачить контейнера · (рів. 3) Ідемпотентність скрипта розгортання: запустити двічі й не зламати

ЛР2 · Dockerfile з багатоетапною збіркою і порівнянням розмірів ⟷ «Кібер-Дієта» (Модуль 1)

Парні теми СРС: (рів. 2) OverlayFS і шари образу: як влаштовано об'єднану файлову систему · (рів. 3) Відтворюваність збірки і довіра до образу (digest, pin версій)

ЛР3 · Простори імен на практиці: два контейнери в ізольованій мережі ⟷ «Сліпий Канал» (Модуль 1)

Парні теми СРС: (рів. 2) Мережі Docker (bridge/none/host) і службове DNS між контейнерами · (рів. 3) Керування секретами: env проти файлів проти docker secrets

ЛР4 · Перший проєкт на Cargo з юніт-тестом ⟷ «Кування Відмички» (Модуль 2)

Парні теми СРС: (рів. 2) Екосистема crates.io, Cargo.toml/Cargo.lock і семантичне версіонування залежностей · (рів. 3) Модель володіння Rust проти збирача сміття і ручного керування пам'яттю

ЛР5 · Набір програм, що не компілюються (borrow checker) ⟷ «Мертвий Лог» (Модуль 2)

Парні теми СРС: (рів. 2) Часи життя (lifetimes) у сигнатурах функцій: що саме перевіряє компілятор · (рів. 3) Rc<T> і RefCell<T>: спільне володіння та внутрішня мутабельність без гонок

ЛР6 · Структури і перелічення без null ⟷ «Архітектура Ворога» (Модуль 2)

Парні теми СРС: (рів. 2) Алгебраїчні типи даних (enum) і вичерпне зіставлення зі зразком (match) · (рів. 3) Патерн «зробити некоректний стан непредставним» (make illegal states unrepresentable)

ЛР7 · Читання файлу з обробкою помилок ⟷ «Мінне Поле» (Модуль 2)

Парні теми СРС: (рів. 2) Result<T, E> проти panic!: коли доречна відновна відмова, а коли зупинка програми · (рів. 3) Власні типи помилок і трейт std::error::Error: Display, Debug, Box<dyn Error>

ЛР8 · Модуль на WAT вручну ⟷ «Пряма Ін'єкція» (Модуль 3)

Парні теми СРС: (рів. 2) Стекова машина WebAssembly і структура текстового формату .wat · (рів. 3) Лінійна пам'ять WASM і межі безпеки пісочниці

ЛР9 · Той самий алгоритм у двох асемблерах ⟷ «Розтин Системи» (Модуль 3)

Парні теми СРС: (рів. 2) Угоди виклику (calling conventions) x86-64: System V AMD64 ABI · (рів. 3) Інструменти дизасемблювання: objdump та wasm-objdump, синтаксис AT&T проти Intel

ЛР10 · Ядро на Rust у WASM на сторінці з відтворюваною збіркою ⟷ «Звільнення» (Модуль 3)

Парні теми СРС: (рів. 2) Межа Rust↔︎JS через wasm-bindgen: маршалінг типів і виклик з JavaScript · (рів. 3) Відтворювані збірки Rust→WASM і цілісність ланцюга постачання (supply chain)

5. Самостійна робота студентів (СРС)

Двадцять тем, по дві на кожну лабораторну: перша готує до захисту (рівень 2), друга — до розширеного завдання (рівень 3). СРС — маршрут до глибини, а не шлагбаум: окремо не здається й не оцінюється, оцінюється рівень лабораторної. Кожна тема має академічне й сюжетне формулювання. Опрацьовується на другій годині відповідного лекційного заняття.

5.1. Шаблон завдання СРС

21. Тема і до якої ЛР/рівня прив'язана.

22. Що прочитати/спробувати — джерела і мінімальна практична проба.

23. Орієнтир самоперевірки — питання, на яке студент має вміти відповісти після опрацювання.

24. Сюжетне формулювання — та сама тема мовою місії С.І.Д.

25. Завдання й контрольні питання.

5.2. Реєстр тем СРС

5.3. Індивідуальний проєкт (необов'язковий)

Наскрізний індивідуальний проєкт — альтернативний шлях до глибини рівня 3: студент бере власну невелику задачу, що поєднує три межі курсу (контейнеризований застосунок на Rust із фрагментом у WebAssembly). Необов'язковий; не є умовою допуску до заліку.

Окремо — позакурсова опція «ядро, що говорить»: інференс крихітної мовної моделі, скомпільований із Rust у WebAssembly і запущений у браузері без сервера. Не оцінюється, не входить у нормативні години й не є частиною жодної ЛР — це фінал для тих, кому мало. Заміри, ліцензії й обґрунтування — docs/private/MODEL_RECON_2026-09.md.

6. Наскрізна сюжетна арка «Проєкт С.І.Д.»

Повний текст історії не дублюється в цьому документі. Він живе там, де його читає студент, і генерується звідти:

• сюжетні версії всіх одинадцяти лабораторних — Лабораторні_сюжет_СІД.docx (той самий прохід генерації, що й цей файл);

• канон світу, календар «ніч 1..10», локації, вміння С.І.Д., стан антагоніста — content/sp/STORY_CANON.md і машинозчитуваний content/sp/canon.yml;

• що кожна ніч додає до наскрізного артефакту — content/sp/ARTIFACT_CHAIN.md.

Причина, чому тут лише посилання, а не текст: до 07.09.2026 в цьому документі лежала власна копія прологу, десяти брифів і епілогу — і саме вона розійшлася з матеріалами настільки, що описувала ранги, яких у курсі немає, і сцени, які переписані. Копія нормативного тексту, яку ніхто не оновлює разом із джерелом, шкідливіша за посилання.

7. Банк тестових питань

Єдиний банк живе в закритому репозиторії дисципліни й ніколи не публікується на GitHub Pages. З нього збираються і модульні тестові контролі, і директорська контрольна. Питання класифікуються за п'ятьма рівнями засвоєння (п. 4.8.2 Положення про НМЗ).

7.1. П'ять рівнів засвоєння

7.2. Структура і квоти

Питання згруповані за модулями і темами лекцій; кожне має рівень (1–5), тип (одна відповідь / кілька / відповідність / короткий ввід) і теги теми. Орієнтовний обсяг — ≈100 питань на модуль (≈300 разом), що дає достатньо для неповторюваних варіантів. Формат зберігання — YAML у репозиторії:

- id: m2-ownership-003

module: 2 # 1..3

topic: ownership # тег теми лекції

level: 3 # рівень засвоєння 1..5

type: single # single | multi | match | short

text: "Що станеться при спробі використати значення після move?"

options: [ ... ]

answer: [ 2 ]

7.3. Модульні тестові контролі

Складаються з банку за квотами рівнів (переважно рівні 1–3, кілька — 4). Результат — орієнтир; основою оцінки лишаються рівні, досягнуті в лабораторних.

7.4. Директорська контрольна робота

8. Календарний план публікації

Матеріали публікуються автоматично за розкладом із конфігурації дисципліни (offering/*.yml). Лабораторна відкривається студентам у день своєї пари, одночасно з лекцією того самого топіка — так тема й практика не розходяться в часі. Конвеєр публікації працює за принципом T-48h: у Classroom матеріали йдуть за 48 годин до відкриття, тобто текст умови й стартовий репозиторій заморожуються за дві доби. Це не зручність, а вимога: умову лабораторної неможливо виправити після того, як студент прийняв завдання — Classroom 50 не доносить оновлення стартера у вже прийняті репозиторії.

Порядок готовності матеріалу до кожної лабораторної:

26. Конспект лекції — до відповідної лекції.

27. Стартовий репозиторій + автотести — до відкриття завдання.

28. Методичні вказівки (обидві версії) — до відкриття завдання, посилання в Classroom.

29. Парні теми СРС — разом із вказівками.

30. Питання банку для модуля — до модульного контролю.

Правило готовності: матеріал готовий за два тижні до пари.

9. Реєстр готовності