Розробити повноцінний звіти для лабораторної роботи "Функції", що присвячена функціям у двох форматів (+їх репрезентація у PDF форматі):
- Markdown.
- doc формат, згідно ДСТУ.
Детальну інформацію можна отримати за посиланнями у стосовних підрозділів розділу "Перелік літератури"
За складом, обидва звіту повинні повністю задовольнять вимогам оформлення звітів, що описаний у початку розділу лабораторних робіт першого семестру.
Починаючи з цієї роботи звіт має бути оформленим у Markdown стилі або у doc форматі згідно ДСТУ (за попередньою домовленістю з викладачем), згідно декларованим вимогам.
У ході виконання роботи, в директорії lab08
повина бути додана папка doc
наступної структури:
.
└── lab08
....
└── doc
├── lab08.docx
├── lab08.pdf
└── lab08.md
Пояснення до структури:
- lab08.pdf - pdf репрезентація файлу lab08.docx. Щоб зробити з docx файлу pdf - треба в MS Word / Libre Writer у меню "Зберегти Як ..." вибрати тип "PDF Document";
- зображення для lab08.md (наприклад, схеми алгоритмів розроблених функцій) повинні бути посиланням на директорію assets лабораторної роботи "Схеми Алгоритмів". При подальшому виконанні завдань, директорія assets повинна розташовуватися в каталозі doc того ж самого проекту.
Зверніть увагу!!!. Усі подальші лабораторні роботи повинні бути виконано з використанням Markdown
- назва кожного пункту меню повинна бути виділена жирним стилем
- усі рисунки повинні бути пронумеровані та мати опис та посилання
- текст коду (у тому числі його частини), структура проекту та результат роботи (якщо програма щось виводить на екран) повинні бути відображені у моноширинному стилі завдяки спец-символам `
Зверніть увагу! У зв'язку з тим, що текст (raw text) у Markdown файлі проходить обробку та є відмінності від результуючого pdf файлу, велике прохання перед тим як видавати викладачу цей файл, спочатку його пере-прочитати на наявність стилістичних розбіжностей !!!
Формат звітів буде трансформуватися з ходом виконання лабораторних. Перші лабораторні роботи мають формат лише звітів. Формат звітів вільний, але викладач має право ввести свої обмеження.
Потім додається схематичний опис розроблених модулів, використання системи автоматичної генерації коду, дотримання ДСТУ та ін.
Звіт складається з розділів. Для кожного розділу вказується номер та його назва. Обов’язковими складовими звіту є:
- Номер роботи та її тема. Ці пункти не нумеруються. Вказується з вирівнюванням по центру рядка.
- ВИМОГИ:
- Розробник. Інформація про розробника: чи є студентом, прізвище, ім'я, по батькові; назва академічної групи; номер варіанту; дата розробки програми.
- Загальне завдання. Зауваження, обмеження та вимоги.
- Індивідуальне завдання. Прикладна задача відповідно до варіанта.
- ОПИС ПРОГРАМИ. Цей підрозділ відповідає за внутрішню роботу програми, її поведінку: калькулювання даних, обробка даних та інші функції програми:
- Функціональне призначення. Призначення програми. Обмеження на застосування.
- Опис логічної структури:
- Якщо використовується об'єктно-орієнтований підхід, навести UML – схему (рисунок), що відображає внутрішню структуру і взаємозв’язки (відносини) розроблених класів, який також створюється засобами doxygen.
- Описати призначення та описати структуру розроблених методів (в тому числі, їх аргументам) та структур / класів, констант та змінних. Матеріалі для даного підрозділу рекомендується брати з результатів згенерованих doxygen документацій. При цьому слід тільки змінити стилі (шрифт, розмір, відступи, колір та інше) і, при необхідності, перевести на українську мову.
- Навести структуру програми. У даному підрозділі достатньо зробити скріншот оглядача рішень з списком файлів та методів. При консольному виконанні - достатньо виконати команду tree в корені проекту, але перед тим необхідно бути завіреним, що усі генеровані дані (бінарники, документація) видалені. Також, структуру програми можна отримати, зробивши скріншот сторінок doxygen документації, що мають перелік файлів та методів.
- Важливі фрагменти програми. Частини тексту програми, що демонструють рішення задачі та короткий (1-2 речення) опис. Обов'язково повинні бути вказані початкові дані.
- ВАРІАНТИ ВИКОРИСТАННЯ. Опис поведінки програми ("хто" і "що" може зробити). Відповідає функціональним вимогам. Ілюструється за допомогою копій екрану з описом. У даному пункті необхідно проаналізувати отримані результати. У разі наявності виведення результатів на екран необхідно навести скріншоти консолі. Якщо робота виконувалася без виведення результатів на екран, подати скріншот вікна відлагоджувача з результатами роботи програми.
- ВИСНОВКИ. Даний пункт не нумерується. Необхідно підвести підсумки і зробити висновки про досягнення мети лабораторної роботи (на основі її теми та завдання) та щодо коректності результатів тестування розробленої програми.
Зверніть увагу! Наведений перелік розділів є рекомендований для викладачів. Тому, за викладачем, що веде лабораторні роботи остається останнє слово за остаточним переліком.
Зверніть увагу. В звіті не потрібно наводити весь код програми! Замість цього краще навести посилання на проект в інтернеті (Github, тощо).
Декілька теорії! Функціональні вимоги (Functional Requirements) - це вимоги до програмного забезпечення, які описують внутрішню роботу системи, її поведінку: калькулювання даних, маніпулювання даними, обробка даних та інші специфічні функції, які має виконувати система. На відміну від нефункціональних вимог, які визначають якою система повинна бути, функціональні вимоги визначають, що система повинна робити. Функціональні вимоги до програмного забезпечення визначаються на першій стадії процесу розробки ПЗ — на етапі аналізу вимог.
- Markdown guide: https://www.markdownguide.org
- СТЗВО-ХПІ-3.01-2018 ССОНП. Текстові документи у сфері навчального процесу. Загальні вимоги до виконання. – (http://blogs.kpi.kharkov.ua/v2/metodotdel/standarti-ntu-hpi/ )
- Утиліта draw.io: https://www.diagrams.net
- Offline markdown editors:
У цієї лабораторній роботі контрольні питання відсутні.