Виконали

студент(-ка) 2-го курсу, групи (шифр групи) [Імʼя Прізвище]
Telegram: @a_boldak

Керівник

доцент кафедри ОТ ФІОТ, к.т.н., доцент Андрій БОЛДАК

НТУУ "КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ імені ІГОРЯ СІКОРСЬКОГО

Факультет інформатики та обчислювальної техніки

Київ

Вступ

У вступі описується мета роботи і розглядається поставлене завдання з позиції її актуальності, значення її розв’язання для тієї предметної області, до якої відноситься тема бакалаврського проєкту.

Коротко характеризується сучасний рівень розв’язання даного завдання і взаємозв’язок з іншими проєктами по цій тематиці.

Наводяться основні технічні характеристики розробки й очікуваний технічно-економічний ефект від її реалізації.

Розроблення загальних вимог до системи

Аналіз предметної області

Вступ

[Вступ повинен містити короткий огляд всього документу.]

Основні визначення

[Розділ містить визначення термінів та скорочень, які використовуються при аналізі предметної області.]

Підходи та способи вирішення завдання

[Розділ містить опис підходів, моделей та способів вирішення завдання.]

Порівняльна характеристика існуючих засобів вирішення завдання

[Розділ містить опис існуючих програм, інформаційних систем, сервісів, тощо, призначених для вирішення завдання. Дається порівняльна характеристика властивостей FURPS:

Functionality (функциональні вимоги)
Usability (вимоги до зручності роботи)
Reliability (вимоги до надійності)
Performance (вимоги до продуктивності)
Supportability (вимоги до підтримки)

(у вигляді таблиці).]

Висновки

[Робляться висновки щодо доцільності розробки нової або модифікації існуючої інформаційної системи, необхідності та способів інтеграції з системами(сервісами) третіх сторін, тощо.]

Посилання

[Розділ містить повний список всіх документів, про які згадується.]

Запити зацікавлених осіб

Вступ

[Вступ повинен містити короткий огляд всього документу.]

Мета

[Визначення мети цієї сукупності вимог. Зазвичай такою метою є створення та впровадження інформаційної системи відповідного призначення.]

Контекст

[Короткий опис того, з якими проектами пов'язаний цей документ, на що він впливає.]

Основні визначення та скорочення

[Розділ містить визначення всіх термінів та скорочень, необхідних для правильного тлумачення вимог. Можна зробити посилання на документ, в якому поданий аналіз предметної області.]

Посилання

[Розділ містить повний список всіх документів, про які згадується.]

Короткий зміст

[Розділ містить опис того, про що йдеться в еій частині цього документу, що залишилася. Також тут описана структура документу.]

Характеристика ділових процесів

[В цьому розділі визначаються зовнішні фактори, що впливають на бізнес (бізнес-актори), та внутрішні фактори (робітники), дається загальна характеристика діяльності бізнес-акторів та робітників, яка здійснюється за допомогою бізнесу.

Дається опис бізнес-сценаріїв взаємодії бізнес-акторів, робітників і, можливо, інформаційної системи за допомогою наступної специфікації:

ID:

НАЗВА:

УЧАСНИКИ:

ПЕРЕДУМОВИ:

РЕЗУЛЬТАТ:

ВИКЛЮЧНІ СИТУАЦІЇ:

ОСНОВНИЙ СЦЕНАРІЙ:

Кількість сценаріїв визначається у відповідності до специфіки завдання та необхідного рівня деталізації (зазвичай, 5-6 сценаріїв).

Короткий огляд продукту

[Визначається границя системи та категорії її користувачів. Дається загальна характеристика категорій користувачів системи]

[Нижче йде опис FURPS:]

Функціональність

[Functionality (функциональні вимоги)]

Практичність

[Usability (вимоги до зручності роботи)]

Надійність

[Reliability (вимоги до надійності)]

Продуктивність

[Performance (вимоги до продуктивності)]

Експлуатаційна придатність

[Supportability (вимоги до підтримки)]

Розроблення функціональних вимог до системи

Модель прецедентів

В цьому файлі необхідно перелічити всі документи, розроблені в проекті та дати посилання на них.

Модель прецедентів повинна містити загальні оглядові діаграми та специфікації прецедентів.

Вбудовування зображень діаграм здійснюється з використанням сервісу plantuml.com.

В markdown-файлі використовується опис діаграми


<center style="
    border-radius:4px;
    border: 1px solid #cfd7e6;
    box-shadow: 0 1px 3px 0 rgba(89,105,129,.05), 0 1px 1px 0 rgba(0,0,0,.025);
    padding: 1em;"
>

@startuml

    right header
        <font size=24 color=black>Package: <b>UCD_3.0
    end header

    title
        <font size=18 color=black>UC_8. Редагувати конфігурацію порталу
        <font size=16 color=black>Діаграма прецедентів
    end title


    actor "Користувач" as User #eeeeaa
    
    package UCD_1{
        usecase "<b>UC_1</b>\nПереглянути список \nзвітів" as UC_1 #aaeeaa
    }
    
    usecase "<b>UC_1.1</b>\nЗастосувати фільтр" as UC_1.1
    usecase "<b>UC_1.2</b>\nПереглянути метадані \nзвіту" as UC_1.2  
    usecase "<b>UC_1.2.1</b>\nДати оцінку звіту" as UC_1.2.1  
    usecase "<b>UC_1.2.2</b>\nПереглянути інформацію \nпро авторів звіту" as UC_1.2.2
    
    package UCD_1 {
        usecase "<b>UC_4</b>\nВикликати звіт" as UC_4 #aaeeaa
    }
    
    usecase "<b>UC_1.1.1</b>\n Використати \nпошукові теги" as UC_1.1.1  
    usecase "<b>UC_1.1.2</b>\n Використати \nрядок пошуку" as UC_1.1.2
    usecase "<b>UC_1.1.3</b>\n Використати \nавторів" as UC_1.1.3  
    
    
    
    User -> UC_1
    UC_1.1 .u.> UC_1 :extends
    UC_1.2 .u.> UC_1 :extends
    UC_4 .d.> UC_1.2 :extends
    UC_1.2 .> UC_1.2 :extends
    UC_1.2.1 .u.> UC_1.2 :extends
    UC_1.2.2 .u.> UC_1.2 :extends
    UC_1 ..> UC_1.2.2 :extends
    
    
    UC_1.1.1 -u-|> UC_1.1
    UC_1.1.2 -u-|> UC_1.1
    UC_1.1.3 -u-|> UC_1.1
    
    right footer
        Аналітичний портал. Модель прецедентів.
        НТУУ КПІ ім.І.Сікорського
        Киів-2020
    end footer

@enduml

**Діаграма прецедентів**

</center>

яка буде відображена наступним чином

Діаграма прецедентів

Проєктування бази даних

В рамках проекту розробляється:

модель бізнес-об'єктів
ER-модель
реляційна схема

Реалізація інформаційного та програмного забезпечення

В рамках проекту розробляється:

SQL-скрипт для створення на початкового наповнення бази даних
RESTfull сервіс для управління даними

Тестування працездатності системи

В цьому розділі необхідно вказати засоби тестування, навести вихідні коди тестів та результати тестування.

Висновки

У висновках наводять оцінку отриманих результатів, можливі галузі його використання. Висновки повинні містити в собі коротку узагальнену оцінку результатів розробки, у тому числі і з погляду на їх технічно-економічну ефективність. Необхідно порівняти отримані результати усіх характеристик об’єкта проєктування із завданням і з основними показниками сучасних аналогічних об’єктів.

Необхідно вказати яке нове технічне рішення покладене в основу проєкту і у чому її переваги, що нового було запропоновано самим студентом.

На базі отриманих висновків можуть надаватися рекомендації по використанню розробки. Вони повинні мати конкретний характер і бути цілком підтверджені проєктом.

Назва проєкту