FPL-Course-2026

Syllabus

Wed, 26 Aug 2026 11:09:16 GMT

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «КИЄВО-МОГИЛЯНСЬКА АКАДЕМІЯ» Факультет інформатики Кафедра інформатики СИЛАБУС ДИСЦИПЛІНИ: Методи розробки програмних системГалузь знань: F Інформаційні технології Спеціальність: F3 Комп'ютерні науки Освітньо-професійна програма: «Комп'ютерні науки», бакалавр1. Обов'язкові компоненти ОП 1.1 Нормативні дисципліниВИКЛАДАЧ: Медвідь С.О., старший викладач кафедри інформатики
E-mail: s.medvid@ukma.edu.uaЗАГАЛЬНЕ НАВАНТАЖЕННЯ: 4 кредити ECTS (120 год.) Заняття в аудиторії: 44 год. (11 лекцій і 11 практичних занять по 2 академічні години) Самостійна робота слухачів курсу: 76 год. Форма підсумкового оцінювання: екзаменКурс знайомить з методами, практиками та інструментами, що використовуються в сучасній розробці програмних систем. Студенти вивчатимуть аналіз вимог, проєктування, конструювання, тестування, рефакторинг та еволюцію програмного забезпечення з особливим акцентом на командній роботі, надійності та професійній практиці. Курс орієнтований на проєкт: студенти поступово застосовують методи в командах для створення працюючої програмної системи, використовуючи процеси та інструменти промислового стандарту. Наскрізна тема 2026 року: розробка з допомогою ШІ. Курс показує, як інструменти ШІ змінюють кожну фазу життєвого циклу і чому специфікація та верифікація стають ключовими інженерними навичками. Розуміти та застосовувати фундаментальні методи для вимог, проєктування, конструювання та валідації програмних систем. Використовувати інструменти спільної розробки (контроль версій, CI/CD, фреймворки тестування, генератори документації). Розвивати навички командної роботи, комунікації та етичної професійної практики в програмній інженерії. Застосовувати стратегії рефакторингу, надійності та еволюції для підтримки довгоживучих систем. Інтегрувати тестування та інженерію надійності в кожну фазу життєвого циклу розробки. Відповідально використовувати інструменти ШІ в розробці: специфікувати завдання, верифікувати результати та розкривати використання згенерованого коду. ЗК1. Здатність до абстрактного мислення, аналізу та синтезу. ЗК2. Здатність застосовувати знання у практичних ситуаціях. ЗК3. Знання та розуміння предметної області та розуміння професійної діяльності. ЗК4. Здатність спілкуватися державною мовою як усно, так і письмово. ЗК6. Здатність вчитися й оволодівати сучасними знаннями. ЗК7. Здатність до пошуку, оброблення та аналізу інформації з різних джерел. ЗК9. Здатність працювати в команді. ЗК10. Здатність бути критичним і самокритичним. ЗК11. Здатність приймати обґрунтовані рішення. ЗК12. Здатність оцінювати та забезпечувати якість виконуваних робіт. ЗК13. Здатність діяти на основі етичних міркувань. СК5. Здатність здійснювати формалізований опис задач дослідження операцій в організаційно-технічних і соціально-економічних системах різного призначення, визначати їх оптимальні розв’язки, будувати моделі оптимального управління з урахуванням змін економічної ситуації, оптимізувати процеси управління в системах різного призначення та рівня ієрархії. СК6. Здатність до системного мислення, застосування методології системного аналізу для дослідження складних проблем різної природи, методів формалізації та розв’язування системних задач, що мають суперечливі цілі, невизначеності та ризики. СК8. Здатність проєктувати та розробляти програмне забезпечення із застосуванням різних парадигм програмування: узагальненого, об’єктно-орієнтованого, функціонального, логічного, з відповідними моделями, методами й алгоритмами обчислень, структурами даних і механізмами управління. СК10. Здатність застосовувати методології, технології та інструментальні засоби для управління процесами життєвого циклу інформаційних і програмних систем, продуктів і сервісів інформаційних технологій відповідно до вимог замовника. СК15. Здатність до аналізу та функціонального моделювання бізнес-процесів, побудови та практичного застосування функціональних моделей організаційно-економічних і виробничо-технічних систем, методів оцінювання ризиків їх проєктування. Курс "Методи розробки програмних систем" забезпечує наступні програмні результати навчання згідно з освітньо-професійною програмою "Комп'ютерні науки": ПРН1. Застосовувати знання основних форм і законів абстрактно-логічного мислення, основ методології наукового пізнання, форм і методів вилучення, аналізу, обробки та синтезу інформації в предметній області комп'ютерних наук. ПРН9. Розробляти програмні моделі предметних середовищ, вибирати парадигму програмування з позицій зручності та якості застосування для реалізації методів та алгоритмів розв'язання задач в галузі комп'ютерних наук. ПРН10. Використовувати інструментальні засоби розробки клієнт-серверних застосувань, проєктувати концептуальні, логічні та фізичні моделі баз даних, розробляти та оптимізувати запити до них, створювати розподілені бази даних, сховища та вітрини даних, бази знань, у тому числі на хмарних сервісах, із застосуванням мов веб-програмування. ПРН11. Володіти навичками управління життєвим циклом програмного забезпечення, продуктів і сервісів інформаційних технологій відповідно до вимог і обмежень замовника, вміти розробляти проєктну документацію (техніко-економічне обґрунтування, технічне завдання, бізнес-план, угоду, договір, контракт). ПРН15. Застосовувати знання методології та CASE-засобів проєктування складних систем, методів структурного аналізу систем, об'єктно-орієнтованої методології проєктування при розробці і дослідженні функціональних моделей організаційно-економічних і виробничо-технічних систем. ПРН16. Розуміти концепцію інформаційної безпеки, принципи безпечного проєктування програмного забезпечення, забезпечувати безпеку комп'ютерних мереж в умовах неповноти та невизначеності вихідних даних. LO1. Застосовувати методи інженерії вимог (виявлення, специфікація, аналіз ризиків). LO2. Проєктувати архітектури програмного забезпечення, API та моделі з увагою до атрибутів якості. LO3. Реалізовувати програмне забезпечення, використовуючи стандарти кодування, фреймворки та практики захисного програмування. LO4. Планувати та виконувати систематичні заходи з тестування та валідації. LO5. Ефективно використовувати інструменти спільної розробки (VCS, CI/CD, інструменти аналізу). LO6. Рефакторити код та керувати еволюцією з семантичним версіюванням та журналами змін (changelogs). LO7. Застосовувати концепції надійності та відмовостійкості до реальних програмних систем. LO8. Демонструвати командну роботу, комунікацію та етичну професійну практику в командному проєкті. Результати навчання курсу підтримують ключові студентські результати (Student Outcomes, SO) ABET, які є фундаментальними здатностями, необхідними для акредитації освітніх програм з комп'ютерних наук. Акредитація ABET гарантує, що випускники можуть ефективно застосовувати інженерні принципи у професійній практиці. Наведене нижче відображення показує, як результати навчання курсу сприяють розвитку здатностей студентів в аналізі проблем, проєктуванні рішень, професійній комунікації та етичній відповідальності -- основних компетенціях, які цінуються роботодавцями та є необхідними для успішної кар'єри в програмній інженерії.Результати навчання цього курсу ретельно узгоджені з областями знань з програмної інженерії згідно з рекомендаціями ACM/IEEE CS2023 Curriculum Guidelines. Структура CS2023 визначає основні компетенції, якими повинні володіти випускники комп'ютерних наук у галузі програмної інженерії, охоплюючи весь спектр від інженерії вимог до надійності систем. Наведене нижче відображення демонструє, як кожен результат навчання курсу безпосередньо відповідає конкретним модулям SE у CS2023, забезпечуючи всебічне охоплення міжнародно визнаних стандартів освіти з програмної інженерії. Структура курсу, цілі, розподіл оцінювання Роль цього курсу в навчальній програмі з комп'ютерних наук Життєві цикли розробки ПЗ: каскадний (Waterfall), ітеративний, гнучкий (agile), DevOps Переваги/обмеження та реальні випадки використання Командна робота: ролі, співпраця, комунікація, вирішення конфліктів, інклюзивність Професійна етика та відповідальність: безпека, захист, конфіденційність, упередженість, сталість Спектр від вайб-кодингу (vibe coding) до агентної інженерії: ШІ стискає життєвий цикл нерівномірно Зміна ролі розробника: від написання коду до специфікації та верифікації Підсумок та огляд лабораторної: налаштування команди, репозиторій, CI Типи вимог: функціональні vs. нефункціональні Методи виявлення: інтерв'ю, користувацькі історії (user stories), варіанти використання (use cases), спостереження Техніки специфікації та документування: користувацькі історії, критерії прийняття, простежуваність Ідентифікація та управління ризиками Вимоги в епоху ШІ: розмова, що породжує специфікацію і прототип одночасно Підсумок та огляд лабораторної: семінар з вимог Роль проєктування ПЗ в життєвому циклі програмної інженерії Архітектурні стилі та шаблони: багатошарова, клієнт-сервер, мікросервіси, керована подіями UML та базове моделювання: діаграми компонентів, діаграми послідовності Відображення вимог на архітектуру Чому архітектура лишається людською фазою: компроміси, яких моделі не бачать Підсумок та огляд лабораторної: чернетки діаграм архітектури Принципи хорошого проєктування API: абстракція, простота, узгодженість Документування API (OpenAPI, Swagger) Атрибути якості та компроміси: надійність, підтримуваність, масштабованість, безпека, зручність використання Проєктні антипатерни та "запахи коду" Підсумок та огляд лабораторної: чернетки API та відображення NFR Важливість конвенцій кодування Безпечне та захисне кодування Ефективне використання бібліотек та фреймворків Документація вихідного коду (docstrings, інструменти автодокументації) Інструменти статичного аналізу та лінтери Безпека згенерованого коду: типові вразливості та статичний аналіз як автоматичний запобіжник Підсумок та огляд лабораторної: каркас проєкту та статичний аналіз Основи тестування ПЗ: модульне (unit), інтеграційне, системне тестування Принципи розробки через тестування (TDD) Стратегії налагодження та логування Автоматизовані фреймворки тестування (JUnit, PyTest) Тести як виконувана специфікація: принцип «тести перед генерацією» Підсумок та огляд лабораторної: написання модульних тестів, практика налагодження Верифікація vs. валідація Планування тестування та матриці Взаємні огляди коду, статичний та динамічний аналіз Безперервне тестування в конвеєрах CI/CD Вузьке місце верифікації: огляд згенерованого коду, оцінювання результату та траєкторії Підсумок та огляд лабораторної: план тестування + взаємні огляди Здоров'я коду, технічний борг та мотивації рефакторингу Поширені патерни рефакторингу (витягнення методу, модуляризація тощо) Принципи еволюції: семантичне версіювання, зворотна сумісність, журнали змін Стратегії міграції та управління ризиками Еволюція з ШІ: рефакторинг успадкованого коду агентами, борг розуміння (comprehension debt) Підсумок та огляд лабораторної: рефакторинг + журнал змін Розрізнення збоїв (faults), помилок (errors) та відмов (failures) Метрики надійності та відмовостійкість Патерни обробки помилок Стратегії резервування та відновлення Проблема 80%: крайні випадки та обробка помилок як незавершена частина згенерованого коду Підсумок та огляд лабораторної: ін'єкція збоїв та тестування надійності Практики безперервної інтеграції та розгортання Автоматизація збірки та тестування Стратегії системного інтеграційного тестування Управління релізами та конвеєри доставки Шлюзи якості (quality gates) для згенерованого коду в CI/CD; фабрична модель розробки Підсумок та огляд лабораторної: конвеєр CI/CD та інтеграційні тести Професійна етика та кодекси (ACM/IEEE) Правові та соціальні питання: ліцензування, конфіденційність, інтелектуальна власність, сталість Економіка розробки з ШІ та відповідальність інженера за згенерований код Презентації командних проєктів Взаємні оцінки та рефлексія щодо командної роботи Підсумок курсу та огляд Артефакти всіх лабораторних публікуються у репозиторії команди, у відповідному підкаталозі docs/. Вага кожної лабораторної в підсумковому рейтингу вказана в дужках; разом 25 балів. Формування проєктних команд (3-4 учасники) Створення командного статуту (ролі, відповідальності, план комунікації) Розділ «Використання ШІ» у статуті: інструменти команди, правила розкриття, правило злиття лише перевіреного згенерованого коду Налаштування Git репозиторію (стратегія гілкування, трекер завдань) Конфігурація CI (GitHub Actions/GitLab CI) Публікація командного статуту та початкових деталей теми проєкту в репозиторії команди Написання користувацьких історій з критеріями прийняття Ідентифікація та документування нефункціональних вимог Створення матриці простежуваності, що пов'язує історії з NFR Публікація документа вимог та матриці простежуваності у docs/requirements/ Створення високорівневої діаграми архітектури (компоненти + з'єднання) Відображення вимог на компоненти архітектури Побудова моделі даних проєкту (ER або доменна модель) Моделювання загроз: аналіз діаграми розгортання за схемою STRIDE, документування виявлених ризиків Використання CASE-засобу моделювання (PlantUML, Lucidchart, UML інструмент) Публікація діаграм архітектури, моделі даних та проєктних нотаток у docs/architecture/ Визначення публічних кінцевих точок API для проєкту Написання специфікації OpenAPI/Swagger Відображення функцій API на NFR (наприклад, час відповіді, безпека) Публікація проєктування API та відображення атрибутів якості у docs/api/ Створення каркасу кодової бази проєкту (налаштування фреймворку) Встановлення стандартів кодування та правил лінтера Інтеграція інструментів статичного аналізу, обов'язково включно з аналізатором безпеки (Bandit, npm audit, SpotBugs або аналог) Виявлення та документування щонайменше однієї потенційної вразливості під час взаємного огляду коду Публікація стандартів кодування, конфігурації інструментів та звіту огляду у docs/code-quality/ Написання початкових модульних тестів для модулів проєкту Запуск тестів зі звітом про покриття Практичні вправи з налагодження (в IDE) Публікація стратегії тестування та підсумку покриття у docs/testing/ Створення чернетки плану тестування з матрицею (модульне/інтеграційне/системне) Проведення взаємних оглядів через pull requests Огляд коду, згенерованого ШІ, за контрольним списком курсу (щонайменше один pull request) Публікація плану тестування та журналів оглядів у docs/validation/ Ідентифікація "запахів коду", застосування патернів рефакторингу Виконання щонайменше одного рефакторингу з допомогою ШІ-агента; нотатка «Використання ШІ» з описом, що згенеровано і як верифіковано Створення журналу змін та збільшення версії проєкту (semver) Запуск регресійних тестів після рефакторингу Аналіз метрик SonarCloud, включно з Security Rating, до та після рефакторингу Публікація оновленого журналу змін та нотаток з рефакторингу у docs/refactoring/ Реалізація обробки помилок у коді проєкту Ін'єкція збоїв для тестування стійкості Документування режимів відмов та стратегії відновлення Публікація звіту про надійність у docs/reliability/ Додавання інтеграційних тестів до проєкту Конфігурація конвеєра CI/CD для автоматизованого тестування та розгортання Перевірка наскрізної системної інтеграції Публікація налаштування конвеєра та результатів інтеграційних тестів у docs/ci-cd/ Індивідуальні презентації (до 5 хвилин на учасника) власного внеску в проєкт Взаємне оцінювання презентацій усіма учасниками групи Рефлексія №2 (оцінюється в межах компонента «Поточні тести та рефлексії», 5 балів), включно з рефлексією про використання ШІ: що делеговано, що верифіковано, які були труднощі Це заняття не є фінальним захистом проєкту: захист відбувається окремо на консультації (див. §10).Форма підсумкового контролю: екзамен (захист фінального проєкту та фінальний тест з теорії).Мінімальна кількість балів для допуску до екзамену: 30 балів (60%) за роботу в семестрі.Тема: Командна розробка програмної системиФінальний проєкт – це семестровий командний проєкт, де студенти застосовують повний життєвий цикл розробки програмних систем: вимоги, проєктування, конструювання, валідація, рефакторинг та доставка.Кожна команда (3-4 студенти) проєктуватиме та створюватиме працюючу програмну систему помірної складності, демонструючи спільну розробку, професійні інструменти та інженерні методи. Інструмент управління завданнями та командами (багатокористувацький веб-додаток з дошками завдань, сповіщеннями та звітами) Система управління подіями кампусу (події, бронювання, зворотний зв'язок, надійність під навантаженням) Панель моніторингу IoT (імітація вводу сенсорів, візуалізація даних, надання попереджень) Трекер бюджету та витрат (багатокористувацький, підтримка звітів, експорт, безпечний вхід) Міні-ТЗ (на етапі пропозиції): мета, функціональні вимоги, обмеження, критерії приймання – одна сторінка Вимоги та аналіз ризиків: щонайменше 10 користувацьких історій, матриця простежуваності, ризики + пом'якшення Проєктування: діаграма архітектури, модель даних (ER або доменна), специфікація API, відображення вимог на проєктування Конструювання: код з використанням стандартів, фреймворків, безпечного кодування, автоматизована документація Тестування та валідація: модульні/інтеграційні/системні тести, взаємні огляди (peer reviews), план тестування Рефакторинг та еволюція: докази рефакторингу, семантичне версіювання, журнал змін Інженерія надійності: обробка помилок, тестування ін'єкції збоїв Інструменти та командна робота: VCS, CI/CD, командний статут, докази співпраці Етика та професіоналізм: заява про конфіденційність, ліцензування, інклюзивність
Використання ШІ: розділ у командному статуті та нотатки «Використання ШІ» в артефактах (див. Політику використання ШІ) Проєкт розвивається інкрементально: кожна лабораторна робота є його черговим етапом, і артефакти лабораторних (§7) є артефактами проєкту. Окремих проєктних дедлайнів поза лабораторними немає. Контрольних точок три: Пропозиція проєкту (Тиждень 1-2): опис теми, ролі користувачів, 5-7 ключових функцій, міні-ТЗ.
Проміжне оцінювання (після Тижня 6, 15 балів): стан документації та здатність системи запускатися. Критерії – в окремому документі «Проміжне оцінювання». Захист фінального проєкту (на консультації, 40 балів): система, репозиторій з CI/CD, документація, фінальний звіт, демонстрація. Документи вимог та проєктування – 10% Реалізація та якість коду – 10% Тестування, валідація та надійність – 10% Фінальний звіт, демо та професійна практика – 10% 25 хвилин на команду: 15 хвилин презентації та 10 хвилин запитань і відповідей Присутність усієї команди обов'язкова; відсутність на захисті означає нульову індивідуальну оцінку за проєкт Демонстрація працюючої системи (розгорнутої онлайн або запущеної локально) та ключових сценаріїв із користувацьких історій Кожен учасник представляє власний внесок; внесок підтверджується історією комітів, відео та взаємним оцінюванням Форми взаємної оцінки, заповнені всіма учасниками Коротке есе-рефлексія (індивідуальне, 1-2 сторінки) про командну роботу та етичні виклики
Захід записується. Детальний регламент і критерії – в окремому документі «Захист фінального проєкту». Єдиний дедлайн для всіх лабораторних результатів: не пізніше, ніж за 24 години до початку наступної лабораторної роботи за розкладом вашої групи. Дедлайн є дедлайном. У час дедлайну автоматичний скрипт "збере" ваші репозиторії для оцінювання; усе, що не закомічено на той момент, не оцінюється. Єдиний виняток – поважна причина, підтверджена медичною довідкою за відповідні дати. Автентичність довідки перевіряється Медичним відділом НаУКМА. Пізні подання без поважних медичних причин не приймаються. Кожна команда підтримуватиме єдиний Git репозиторій для проєкту. Документація проєкту організована за темами в каталозі docs/: docs/requirements/ – вимоги, користувацькі історії, матриця простежуваності docs/architecture/ – діаграми, модель даних, ADR, модель загроз docs/api/ – специфікація API та атрибути якості docs/code-quality/ – стандарти, статичний аналіз, звіти оглядів docs/testing/, docs/validation/ – стратегія тестування, план тестування, журнали оглядів docs/refactoring/, docs/reliability/, docs/ci-cd/ – артефакти відповідних лабораторних Посилання на індивідуальні відео подаються у Labs/LabNN/video_[ваше_ім'я].txt. Всі файли подання та посилання на відео-описи повинні бути закомічені до дедлайну. На додаток до командних результатів, кожен студент повинен подати коротку відео-презентацію (максимум 5 хвилин, це важливо) для кожного основного результату проєкту. Мета: продемонструвати ваш індивідуальний внесок у командний проєкт. Відео повинно включати: Демонстрацію екрану вашого коду / документа / тесту / конфігурації CI тощо. Коротке голосове пояснення того, що ви зробили, ключові рішення та як це вписується в проєкт. Формат подання: Створіть текстовий файл у папці результату з вашим посиланням на відео Loom (або подібне). Назва файлу: video[вашеім'я].txt Приклад: Lab02/video_oleksandra_peliukh.txt Не завантажуйте саме відео в репозиторій. Потрібне лише посилання. Безкоштовних акаунтів Loom достатньо для цієї мети. На середині проєкту (Тиждень 6) та перед захистом студенти заповнюватимуть конфіденційну взаємну оцінку. Критерії (оцінка 1-5 за кожним): якість внеску, надійність (відвідуваність, дотримання дедлайнів), співпраця, ініціативність. Взаємна оцінка є однією зі складових індивідуального коефіцієнта внеску (див. «Коригування оцінок» нижче), а не окремою поправкою до оцінки. Лабораторні розроблені для практичної роботи та моніторингу прогресу. Фіналізовані результати повинні бути подані в репозиторії, навіть якщо більша частина роботи виконується вдома. Історія комітів репозиторію буде перевірятися для підтвердження активної участі всіх членів команди. Оцінка за проєкт є командною, але індивідуальна оцінка кожного учасника обчислюється з неї за формулою:Індивідуальна оцінка = Командна оцінка × Множник допуску × Коефіцієнт внеску Множник допуску відображає виконання обов'язкових умов: присутність на захисті (обов'язкова: за відсутності індивідуальна оцінка дорівнює нулю), есе-рефлексія, значущі коміти, відео та жива презентація, заповнена взаємна оцінка. За виконання всіх умов множник дорівнює 1,0. Коефіцієнт внеску лежить у діапазоні 0,5-1,2 і поєднує три незалежні джерела: аналіз репозиторію (історія комітів, авторство коду, участь в оглядах PR) – 50%, взаємна оцінка – 30%, якість відповідей на захисті – 20%. Учасники, які системно працюють нижче рівня команди, отримують нижчу оцінку, ніж базова командна; виняткові учасники – вищу, до 120% базової. Розбіжність між джерелами (наприклад, високий обсяг комітів за низької взаємної оцінки) є підставою для ручного перегляду викладачем.
Детальний регламент, шкали та приклади обчислення – в окремому документі «Захист фінального проєкту».
Цей контрольний список підсумовує тижневі результати для курсу "Методи розробки програмних систем". Кожен пункт повинен бути поданий до дедлайну відповідного тижня. Всі подання повинні бути закомічені в командний репозиторій з включеними індивідуальними посиланнями на відео Loom не пізніше, ніж за 24 години до початку наступної лабораторної роботи за вашим розкладом в офіційно призначеній групі.
IEEE Computer Society. SWEBOK Guide v4.0: Guide to the Software Engineering Body of Knowledge. IEEE, 2024. Електронний ресурс (копія в репозиторії курсу: references/swebok-v4.pdf) – базове джерело для тем 1-11
ACM/IEEE-CS Joint Task Force. CS2023: Computer Science Curricula 2023. ACM, 2023. Електронний ресурс – модулі SE та SEP DORA / Google Cloud. State of AI-assisted Software Development, 2025. (копія в репозиторії курсу: references/2025_state_of_ai_assisted_software_development.pdf) – метрики DORA, тема 10
Osmani, A., Saboo, S. & Kartakis, S. The New SDLC With Vibe Coding. Google, 2026. Kaggle (копія в репозиторії курсу: references/2026_the_new_sdlc_with_vibe_coding.pdf) – наскрізна тема ШІ; теми 1, 7, 8, 11 Sommerville, I. Software Engineering, 10th Ed. Pearson, 2016 – розділи 1-4 (життєвий цикл, вимоги), доступно в бібліотеці НаУКМА Pressman, R. & Maxim, B. Software Engineering: A Practitioner's Approach, 9th Ed. McGraw-Hill, 2020 – розділи з проєктування та тестування, доступно в бібліотеці НаУКМА Bass, L., Clements, P. & Kazman, R. Software Architecture in Practice, 4th Ed. Addison-Wesley, 2021 – тема 3 Forsgren, N., Humble, J. & Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018 – тема 10, походження метрик DORA Beyer, B. et al. Site Reliability Engineering. O'Reilly, 2016 та The Site Reliability Workbook. O'Reilly, 2018 – тема 9 (SLI, SLO, бюджет помилок) Fowler, M. Refactoring: Improving the Design of Existing Code, 2nd Ed. Addison-Wesley, 2018 – тема 8 Feathers, M. Working Effectively with Legacy Code. Prentice Hall, 2004 – тема 8 (характеризаційні тести) Martin, R.C. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2008 – тема 5
Atlassian Git Tutorials – навчальні матеріали з Git
Atlassian CI/CD Tutorials – навчальні матеріали з CI/CD
OWASP Secure Coding Practices – керівництва з безпечного кодування
GitHub Docs – документація GitHub Метод викладання Лекції – Сесії, зосереджені на концепціях, з кейсами, реальними прикладами та обговоренням. Лекції представляють теорію та методи, часто безпосередньо пов'язуючи з тижневою лабораторною роботою та результатами проєкту. Лабораторні роботи – Керовані практичні сесії, де студенти починають практичну роботу над тижневими завданнями та командним проєктом. Хоча лабораторні наголошують на співпраці в класі, фінальні результати повинні бути закомічені в командний репозиторій до дедлайну. Документація у GitHub – Всі матеріали курсу (силабус, конспекти лекцій, лабораторні завдання, завдання, опис проєкту) розміщені у GitHub репозиторії курсу. Викладачі та асистенти підтримують структуру і матеріали курсу, тоді як студенти додають свій внесок, документуючи прогрес проєкту своєї команди, діляться рішеннями та редагують спільні ресурси. Документація командних проєктів – Кожна команда веде документацію свого проєкту в каталозі docs/ власного репозиторію: статут, вимоги, проєктні рішення, результати лабораторних та посилання на демо. Це забезпечує прозорість прогресу та сприяє відповідальності, а також робить документацію об'єктом оцінювання нарівні з кодом. Підтримка – Години консультацій, дискусійні форуми та сесії зворотного зв'язку за проєктом. Курс викладається як поєднання традиційних лекцій, практичних лабораторних робіт та спільної роботи над документацією. Markdown-документація в репозиторіях курсу та команд слугує центральним хабом для контенту курсу та командної роботи, роблячи сам курс вправою в професійній документації та обміні знаннями. Студенти вчаться не лише розробляти програмні системи, але й документувати, пояснювати та комунікувати свою роботу в спільному середовищі: ключові навички для реальних інженерних команд.Виконання навчальних завдань і робота в курсі має відповідати вимогам «Положення про Академічну доброчесність здобувачів освіти у НаУКМА» (затверджене наказом № 112 від 07.03.2018 року)
https://www.ukma.edu.ua/index.php/about-us/sogodennya/dokumenty-naukma/cat_view/1-dokumenty-naukma/12-normatyvna-baza-naukma/6-systema-zabezpechennia-iakosti-osvitnoi-diialnosti-ta-iakosti-vyshchoi-osvity/71-normatyvni-dokumenty
Використання інструментів штучного інтелекту регулюється документом «Політика використання штучного інтелекту». Розкрите і верифіковане використання ШІ не є порушенням академічної доброчесності; приховане, неверифіковане або сфабриковане використання розглядається як порушення.Затверджено на засіданні кафедри інформатики факультету інформатики _ ____ 2025 р. (Протокол № ___)

Методи розробки програмних систем

Wed, 26 Aug 2026 11:00:19 GMT

НаУКМА, Факультет інформатики – осінь 2026Курс знайомить з методами, практиками та інструментами, що використовуються в сучасній розробці програмних систем: аналіз вимог, проєктування, конструювання, тестування, рефакторинг та еволюція програмного забезпечення, з особливим акцентом на командній роботі, надійності та професійній практиці. Курс орієнтований на проєкт: студенти поступово застосовують методи в командах для створення працюючої програмної системи. Наскрізна тема 2026 року: розробка з допомогою ШІ і те, чому специфікація та верифікація стають ключовими інженерними навичками.📄 Силабус курсу
🤖 Політика використання ШІМатеріали лекцій і лабораторних з'являтимуться тут поступово впродовж семестру.

AI-Policy

Wed, 26 Aug 2026 08:43:24 GMT

Ця політика поширюється на всі роботи в курсі «Методи розробки програмних систем»: лабораторні, командний проєкт, документацію та відповіді на захисті.Використання інструментів ШІ (кодових агентів, асистентів, чат-моделей) у цьому курсі дозволене й очікуване. Ми готуємо вас до індустрії, де, за оцінками Google станом на 2026 рік, більшість професійних розробників регулярно користується кодовими агентами, а значна частка нового коду генерується ШІ.Водночас курс розрізняє два кінці спектра, описаного в документі Google «The New SDLC With Vibe Coding» (2026): «вайб-кодинг» (vibe coding), тобто разові підказки й неперевірений одноразовий код, та агентну інженерію з формальними специфікаціями, автоматизованими тестами та перевірками в CI/CD. Різниця не в тому, чи використано ШІ, а в тому, як верифіковано результат. У цьому курсі ми працюємо на інженерному кінці спектра. Розумійте. Ви відповідаєте за кожен рядок, який здаєте, незалежно від того, хто чи що його написав. У відео та на захисті ви маєте вміти пояснити свій внесок; нездатність пояснити власний код впливає на індивідуальну оцінку (див. Силабус, §11). Верифікуйте. Згенерований код проходить ті самі механізми, що й написаний вручну: перегляд перед комітом, тести, статичний аналіз, взаємний огляд. Неперевірений згенерований код не потрапляє в основну гілку. Розкривайте. Командний статут (Лабораторна 1) фіксує, які інструменти ШІ команда використовує і за якими правилами. Артефакти лабораторних містять коротку нотатку «Використання ШІ»: що згенеровано або зроблено з допомогою ШІ і як це перевірено. На пряме запитання викладача про використання ШІ відповідь має бути точною. Здати роботу, яку ви не можете пояснити. Злити в основну гілку згенерований код без перегляду і тестів. Приховати використання ШІ або заперечити його у відповідь на пряме запитання. Сфабрикувати артефакти: вигадані результати тестів, неіснуючі джерела, звіти про роботу, якої не було. Передати в зовнішні сервіси персональні дані одногрупників або закриті матеріали курсу. Розкрите і верифіковане використання ШІ не знижує оцінку. Порушення цієї політики розглядається як порушення академічної доброчесності (Силабус, §15). Osmani, A., Saboo, S., Kartakis, S. The New SDLC With Vibe Coding. Google, 2026. Копія в репозиторії курсу: references/2026_the_new_sdlc_with_vibe_coding.pdf «Положення про академічну доброчесність здобувачів освіти у НаУКМА» (посилання в Силабусі, §15)

UKMA-logo

Sun, 16 Aug 2026 14:19:25 GMT