Інженерія програмних продуктів та сервісів

Анотація навчальної дисципліни

Мета дисципліни
формування у здобувачів вищої освіти цілісної системи знань та вмінь щодо процесу та окремих фаз розробки програмних продуктів та сервісів

Завдання дисципліни: 
сформувати у здобувачів вищої освіти знання основних етапів життєвого циклу програмного продукту, розуміння процесу розробки програмних продуктів та сервісів, розуміння принципів організації робіт в крос-дисциплінарних командах, вміння розробляти програмні продукти або сервіси низької складності.

Основні результати навчання

ПР05. Знати і застосовувати відповідні математичні поняття, методи доменного, системного і об’єктно-орієнтованого аналізу та математичного моделювання для розробки програмного забезпечення.
ПР07. Знати і застосовувати на практиці фундаментальні концепції, парадигми і основні принципи функціонування мовних, інструментальних і обчислювальних засобів інженерії програмного забезпечення.

Форми організації освітнього процесу та види навчальних занять

Л – лекційні заняття; ПЗ – практичні заняття – практична підготовка до і активна участь в проектуванні архітектури безпосередньо на занятті; СРЗ – самостійна робота здобувача вищої освіти; К – консультації викладача, МКР – модульна контрольна робота.

Тематика та види навчальних занять

1 тиждень
Л1. Інженерія програмного забезпечення в аспекті розробки продуктів та сервісів. Основи програмної інженерії. Супроводження або еволюція. Етика програмної інженерії. Процес розробки ПЗ. SEMAT. Процес розробки продукту.
ПЗ1. Визначення ідеї продукту або сервісу
СРЗ, К

2 тиждень
Л2. Планування бізнесу. Підприємницькі можливості. Lean стартап. Lean канва. Роль маркетингу.
СРЗ, К

3 тиждень
Л3. Формування команди та визначення ролей.
ПЗ2. Бізнес-планування
СРЗ, К

4 тиждень
Л4. Специфікація продукту. Бізнес-вимоги. Бізнес-правила. Вимоги користувача. Атрибути якості. Функціональні вимоги. Системні вимоги. Ролі бізнес-аналітика та володаря продукту.
СРЗ, К

5 тиждень
Л5. Збирання та документація вимог: історії користувача, варіанти використання. Беклог та карти історій. Специфікація функціональних вимог. 
ПЗ3. Специфікація вимог до програмного продукту
СРЗ, К

6 тиждень
Л6. Трасування вимог. Парадигма вбудовування якості в програмній інженерії. Управління вимогами.
СРЗ, К

7 тиждень
Л7. Архітектура продукту. Статична та динамічна структура. Архітектурне подання, точка зору та перспектива. Використання стилів та шаблонів.
ПЗ4. Специфікація вимог до програмного продукту
СРЗ, К, МКР1

8 тиждень
Л8. Розробка архітектурної моделі. Валідація архітектури. Lean архітектура.
СРЗ, К

9 тиждень
Л9. Розробка продукту в крос-дисциплінарних командах. Моніторинг та контроль виконання робіт.
ПЗ5. Проектування інтерфейсу користувача
СРЗ, К

10 тиждень
Л10. UI/UX. Цілі проекту та потреби користувачів. Орієнтований на користувача дизайн. Варфрейми, мокапі та прототипи. Onboarding та journey maps. Стадії розробки продукту.
СРЗ, К

11 тиждень
Л11. Контроль якості програмних продуктів. Класифікація причин помилок в програмних продуктах. Компоненти системи забезпечення якості програмного продукту. Елементи плану якості. Верифікація, валідація та класифікація.
ПЗ6. Забезпечення якості
СРЗ, К

12 тиждень
Л12. Тестування програмного забезпечення. Покриття тестами. Планування тестування. Альфа- та бета-тестування. Метрики якості програмного забезпечення. Вартість якості програмного забезпечення.
СРЗ, К

13 тиждень
Л13. Захищеність і безпека програмних продуктів. Людські та організаційні аспекти захищеності та безпеки. Роль стандартів захищеності та безпеки. Аналіз загроз і техніки захисту. Забезпечення захищеності та безпеки. 
ПЗ7. Планування реалізації програмного продукту
СРЗ, К

14 тиждень
Л14. Управління змінами. Промислова розробка програмних продуктів: процес-метод-лідерство.
СРЗ, К, МКР2

15 тиждень
Л15. Стратегічне планування та дорожня карта продукту. 
ПЗ8. Пітчинг розроблених концепцій програмних продуктів або сервісів
СРЗ, К

Індивідуальна робота

Розрахунково-графічна робота (РГР) виконується згідно з графіком навчального процесу. На її виконання відводиться 15 годин індивідуальної роботи студента. Робота повинна підтвердити опанування студентом дисципліни та прищепити навички самостійної розробки, розробки та забезпечення якості програмних продуктів.
Тематика РГР періодично зазнає уточнення і коригування. РГР виконується окремо кожним студентом.
Етапи виконання РГР:
    видача завдань (1-2 тиждень);
    самостійна робота студентів (3-14 тиждень);
    захист РГР (15 тиждень).

Процедура оцінювання

Система оцінювання рівня навчальних досягнень ґрунтується на принципах ЄКТС та є накопичувальною. Здобувачі протягом семестру готуються до лекційних та практичних занять, виконують 2 модульні контрольні роботи та РГР.
Для забезпечення оперативного контролю за успішністю та якістю рівня навчальних досягнень здобувачів вищої освіти дисципліна поділяється на два семестрові модулі.

Семестровий модуль № 1
Оцінка за виконання практичних робіт (1 – 3) – 20 балів. Термін надання виконаних робіт – до 7 тижня.
МКР1 – 30 балів (7 тиждень). 
Перескладання можливе протягом 9 – 11 тижнів за розкладом консультацій.
Семестровий модуль № 2
Оцінка за виконання практичних робіт (4 – 5) – 10 балів. Термін надання виконаних робіт – до 14 тижня.
МКР2 – 30 балів (14 тиждень). 
Оцінка за виконання РГР – 10 балів  (15 тиждень).

Максимальна оцінка, яку може отримати здобувач за всі виконані види робіт – 100 балів. 

Підсумковим контролем з дисципліни є залік.

Умови допуску до підсумкового контролю

Залік виставляється здобувачу вищої освіти як сумарна оцінка за виконання всіх елементів навчальної дисципліни не менше ніж на 60%.

Політика освітнього процесу

1. Аудиторні заняття
    Якщо Ви прийшли в аудиторію на заняття, то маєте працювати разом з професором. Відповідно ви маєте приходити на заняття підготовленими, розібравши теоретичний матеріал та виконавши завдання, якщо вони були
    Якщо Ви пропустили попередні заняття, то маєте розібрати їх матеріал самостійно до початку наступного заняття
    Якщо Ви запізнюєтеся, то маєте тихо зайти до аудиторії і сісти на вільне місце, не відволікаючи решту
    Відвідування лекцій не контролюється і не оцінюється. Якщо Вам терміново потрібно зробити іншу роботу під час заняття, то Ви робите її поза межами аудиторії
    Звук мобільних телефонів та інших гаджетів має бути вимкнено під час заняття. Якщо Вам конче потрібно відповісти на дзвінок, то маєте тихо вийти з аудиторії.

2. Самостійна робота
    Ви маєте регулярно готуватися до лекційних і практичних занять, виконувати до зазначених дедлайнів завдання на самостійну та індивідуальну роботу
    Поведінка free-rider не відповідає принципам Кодексу етики фахівців з програмної інженерії

3. Оцінювання
    Всі оцінювані роботи здаються на перевірку лише через платформу el.opu.ua
    На протязі вивчення дисципліни підтримується політика нульової толерантності до списування
    Роботи з ознаками запозичень без посилань оцінюються нулем балів. Якщо кільки робіт містять однакові відповіді, то всі вони отримують нуль, пошук першоджерела не виконується.
    Робота, що містить відповіді на чужий варіант завдання, оцінюється нулем балів
    Роботи після дедлайну на перевірку не приймаються
    Виключення з правила дедлайну надається лише у випадку неможливості здати роботу на перевірку з поважних причин, які визнані деканатом. Тобто з питаннями щодо здачі робіт після реченця до професора слід звертатися лише за умови наявності дозволу з деканату.
    Повторний доступ до здачі надається лише для модульних контрольних робіт (МКР). Повторний доступ до МКР1 надається з 9 до 14 тижня в семестрі, повторний доступ до обох МКР надається після завершення семестру.
    В МКР оцінюються лише відповіді на запитання. Будь-який зайвий текст бали не додає. Якщо відповідь містить загальні визначення, на підставі яких професор має самостійно сконструювати відповідь, відповідь вважається некоректною.
    Складання/перескладання екзаменів виконується за встановленим деканатом розкладом.

4. Консультації
    Консультації проводяться за розкладом консультацій. На сходах, в коридорах і будь-яких інших не зазначених в розкладі локаціях консультації не надаються. 
    На консультацію слід приходити з сформульованими питаннями і Вашими варіантами відповіді на них. Якщо Ви нічого не зробили самостійно для вирішення питання, то з великою ймовірністю консультація Вам не потрібна.
    Під час консультації професор не виконує Вашу роботу і не перевіряє коректність Вашої роботи, а лише відповідає на запитання. Отже ретельно готуйте свої питання.

Література

Базова
1. Hans van Vliet. Software Engineering: Principles and Practice. – John Wiley & Sons, 2008. – 740 p.
2. Luke Hohmann. Beyond Software Architecture: Creating and Sustaining Winning Solutions. – Addison Wesley, 2003. – 352 p.
3. Wiegers, K. Software Requirements / K. Wiegers, J. Beatty. – Microsoft Press, 2013. – 672 p.
4. Garrett, J. J. The Elements of User Experience (2nd ed.). – New Riders Publishing, 2010. – 192 p.
5. Daniel Galin. Software Quality Assurance: From Theory to Implementation. – Addison-Wesley, 2003. – 616 p.

Додаткова
6. Nick Rozanski & Eóin Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. – Addison Wesley, 2011. – 704 p.
7. Unger, R., Chandler, C. A Project Guide to UX Design – For User Experience Designers in the Field or in the Making. – New Riders Publishing, 2012.

Методична
8. Методичні вказівки до лабораторних робіт з дисципліни «Інженерія програмних продуктів та сервісів» для студентів спеціальності 121 – Інженерія програмного забезпечення / Укл.: В. В. Любченко. – Одеса: ОНПУ, 2019. – 16 с.