МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЛЬВІВСЬКА ПОЛІТЕХНІКА»

МЕТОДИЧНІ ВКАЗІВКИ
ДО ВИКОНАННЯ КУРСОВОЇ РОБОТИ З КУРСУ
“МЕТОДОЛОГІЇ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ”

Затверджено на засіданні кафедри “Інформаційні

системи та мережі” Протокол № 1 від 30.08.2023 р.

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

Укладач: Басюк Т. М., к.т.н., доцент кафедри ІСМ

 Вступ
Дані методичні вказівки до виконання курсової роботи з дисципліни «Методології
проектування інформаційних систем» написані у відповідності з робочою програмою
дисципліни. Під час курсового проектування відпрацьовується технологічний процес
розробки програмного продукту: технічне завдання, зовнішнє і внутрішнє проектування,
кодування, тестування, розробка і оформлення документації.
В результаті виконання курсової роботи студенти повинні показати знання:
• характеристик і можливостей середовищ проектування;
• прийомів роботи з середовищами програмування;
• видів програм, програмної та експлуатаційної документації.

Студенти повинні вміти:

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

Мета роботи
Метою курсової роботи є закріплення і розширення теоретичних знань і практичних
навичок проектування студента, який повинен показати вміння і навики застосовувати
теоретичні положення дисципліни «Методології проектування інформаційних систем»;
грамотно, самостійно і творчо вирішувати завдання; чітко і логічно викладати свої думки і
рішення; аналізувати отримані результати і робити необхідні висновки.
Завданням курсової роботи є самостійне виконання студентом проектування та
розробки програмного продукту відповідно до технічного завдання. Студент при цьому
повинен показати свій рівень підготовки, вміння вибрати і обґрунтувати рішення с, навички
роботи з технічною та довідковою літературою, вміння застосовувати обчислювальну
техніку в своїй діяльності

Організація курсового проектування

У роботі студента над курсовою роботою умовно можна виділити три етапи. Перший
етап – підготовчо-організаційний, протягом якого усвідомлюється завдання, визначаються
можливі варіанти вирішення поставленого завдання, підбирається необхідна література,
складається календарний план виконання курсової роботи.
Другий етап – власне робота над курсовою роботою, тобто розробка робочої версії
програмного додатку (програми, програмного комплексу). В результаті цього етапу повинна
бути виконана структуризація завдання, розроблена методологія вирішення задачі,
спроектовано інтерфейс, виконана програмна реалізація, проведені тестування й
налагодження. Третій етап – оформлення пояснювальної записки до курсової роботи.
Керівник курсової роботи:
• видає індивідуальне завдання на курсову роботу;
• визначає календарний графік виконання роботи;
• рекомендує студентові необхідну літературу, довідкові матеріали, інші джерела
інформації;
• контролює виконання основних етапів роботи.
Відсоток виконання роботи у визначені строки фіксується керівником. У
випадку, коли робота виконується із відставанням від графіку без поважних причин,
керівник зобов'язаний понизити студентові оцінку. Перед початком виконання роботи
кожен студент отримує від керівника індивідуальне завдання.
За вірність результатів роботи відповідає її виконавець.

Склад та обсяг курсової роботи

Курсова робота складається з двох основних частин: пояснювальної записки та
електронної версії програмного продукту. У пояснювальній записці повинен бути розкритий
творчий задум проекту, описані методи, що застосовуються при його розробці, дано
обґрунтування прийнятих рішень шляхом порівняння можливих варіантів. Текст повинен
містити розрахунки, графіки, діаграми. Потрібно привести вихідні дані, підготовлені до
введення, і отримані результати. Особливу увагу необхідно приділити осмисленню та оцінці
отриманих результатів. Необхідно використовувати сучасні літературні джерела або
зареєстровані сайти фірм виробників комплектуючих і програмних продуктів з посиланнями
на авторів і торгові марки, не слід використовувати реферати та літературу з технічним
жаргоном і вузько спеціальною термінологією.
Рекомендований зміст пояснювальної записки:
• титульний аркуш;
• завдання на курсову роботу;
• анотація українською мовою;
• зміст;
 • вступ;
• основна частина;
• висновки;
• список використаних джерел;
• додатки.

Структура пояснювальної записки:

ТИТУЛЬНИЙ АРКУШ має форму стандартного бланка та наведений в додатку 1.
ЗАВДАННЯ ТА КАЛЕНДАРНИЙ ПЛАН ВИКОНАННЯ має форму стандартного
бланка. Зразок оформлення наведений в додатку 2.
АНОТАЦІЯ українською мовою обсягом до 1 сторінки (до 1200 друкованих знаків).
ЗМІСТ містить послідовно перелічені назви (заголовки) та номери аркушів початку
складових пояснювальної записки (вступ, обов’язкові розділи та відповідні їм підрозділи,
пункти і підпункти, якщо останні мають заголовки, висновки, список використаних джерел,
додатки). Рекомендована глибина нумерації розділів – не більше 3 (1.1.1,…).
ВСТУП розміщують у пояснювальній записці, починаючи з аркуша, наступного після
закінчення змісту, обсягом 2-3 сторінки.
У вступі рекомендовано:
• навести загальні відомості щодо сучасного стану і перспектив розвитку об’єкту
проектування;
• обґрунтувати актуальність теми і мету роботи та навести короткий огляд сучасних
розробок за темою;
• відобразити науково-технічну новизну і значення основних положень (рішень);
• стисло висвітлити проблематику питання, зазначаючи розв’язані задачі галузі.
РОЗДІЛИ ОСНОВНОЇ ЧАСТИНИ. Основну частину розміщують у пояснювальній
записці, починаючи з аркуша, наступного після закінчення вступу, обсягом 30 – 50 сторінок.
Матеріал основної частини поділяється на розділи, підрозділи, пункти і підпункти (якщо
останні мають заголовки) і відображає вирішення студентом поставлених завдань з
врахуванням вимог до змісту курсового проекту і рекомендацій керівника, починаючи з
аналізу вхідних даних і завершуючи висновками.
Кожний розділ починають з нового аркуша. Виклад матеріалу повинен бути
конкретним і повинен відображати в основному результати, отримані студентом
самостійно. При використанні загальновідомих речей обов’язкове посилання на відповідне
джерело.
 ВИСНОВКИ. Висновки обсягом 1 – 2 сторінки розміщують у пояснювальній записці,
починаючи з аркуша, наступного після закінчення матеріалу основної частини. У висновках
наводяться найважливіші теоретичні та практичні результати, які отримані в роботі і які
корелюються із поставленими завданнями.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ. Список використаних джерел розміщують
у пояснювальній записці, починаючи з аркуша, наступного після закінчення висновків.
ДОДАТКИ. Додатки розміщують у пояснювальній записці, починаючи з аркуша,
наступного після закінчення списку використаних джерел. У додатках наводять матеріал,
який:
• є необхідним для повноти висвітлення результатів, але введення його до основного
матеріалу пояснювальної записки може обтяжити її та змінити впорядковане й
логічне уявлення про роботу;
• не може бути послідовно розміщений в основному матеріалі пояснювальної записки
через великий обсяг або способи його відтворення.
Кожен додаток повинен починатися з нової сторінки. Додаток повинен мати
заголовок, надрукований вгорі малими літерами з першої великої симетрично відносно
тексту сторінки. Посередині рядка над заголовком малими літерами з першої великої
друкується слово "Додаток X" та велика літера, що позначає додаток. Додатки слід
позначати послідовно великими літерами української абетки, за винятком літер Г, Є, І, Ї, Й,
О, Ч, Ь, наприклад, "Додаток А", "Додаток Б" і т.д. Один додаток позначається як "Додаток
А". Текст кожного додатка за необхідності може бути поділений на розділи й підрозділи, які
нумерують у межах кожного додатка. У цьому разі перед кожним номером ставлять
позначення додатка (літеру) і крапку, наприклад. А.2 - другий розділ додатка А; В.3.1 –
перший підрозділ третього розділу додатка В.
Ілюстрації, таблиці і формули, які розмішені в додатках, нумерують у межах кожного
додатка, наприклад: рис. А.1.2 – другий рисунок першого розділу додатка А; формула (В.1) –
перша формула додатка В.
Пояснювальна записка курсової роботи може містити графічний матеріал, який
виконують на аркушах формату А4 згідно з чинними вимогами.
 Структура розділів основної частини
ВСТУП
У вступі необхідно лаконічно сформулювати суть і стан проблеми (завдання) та її
значущість, підстави і вихідні дані для розроблення теми, обґрунтування необхідності
виконання дослідження. Далі подається загальна характеристика роботи в такій
послідовності.
Актуальність теми. Шляхом критичного аналізу та порівняння з відомими
розв’язаннями проблеми (наукової задачі) слід обґрунтувати актуальність та доцільність
роботи для розвитку відповідної галузі науки чи виробництва.
Мета і задачі дослідження. Необхідно сформулювати мету роботи і охарактеризувати
задачі, які необхідно вирішити для досягнення поставленої мети. Не слід формулювати мету
як "Дослідження...", "Вивчення...", оскільки ці слова вказують на засіб досягнення мети, а не
на саму мету.
Об’єкт дослідження – це процес або явище, що породжує проблемну ситуацію і
обране для вивчення.
Предмет дослідження міститься в межах об’єкта. Об’єкт і предмет дослідження як
категорії наукового процесу співвідносяться між собою як загальне і часткове. Предметом
дослідження може бути частина об’єкту (явища або процесу), або певний аспект (погляд)
об’єкту в цілому (процесу або явища). Саме на нього скерована основна увага розробника,
оскільки предмет дослідження визначає тему курсового проекту.
Практичне значення одержаних результатів. У курсовій роботі, що має теоретичне
значення, треба подати відомості про наукове використання результатів досліджень чи
рекомендації щодо їх використання, а в роботі, що має прикладне значення, - відомості про
практичне застосування одержаних результатів чи рекомендації щодо їх використання.
Відзначаючи практичну цінність одержаних результатів, необхідно подати інформацію щодо
ступеня готовності до використання.

1. АНАЛІЗ ЛІТЕРАТУРНИХ ДЖЕРЕЛ ТА ПРЕДМЕТНОЇ ГАЛУЗІ

1.1. Основні засади дослідження
Початковим етапом роботи над курсовим проектом є знайомство з висвітленням
обраної теми в наукових джерелах. Результатом цього має стати бібліографічний огляд
літератури, який характеризує стан дослідження теми. В огляді літератури необхідно
окреслити основні етапи розвитку наукової думки за досліджуваною проблемою. Стисло,
критично висвітлюючи роботи попередників, студент повинен назвати ті питання, що
залишились невирішеними і, отже, визначити своє місце у розв’язанні задачі.
 1.2. Аналіз відомих засобів вирішення проблеми
В даному підрозділі приводиться деталізований опис та порівняння існуючих
системам-аналогів та наводиться їх сильні та слабкі сторони, які детально аналізуються.
Результатом аналізу є перелік особливостей, що необхідно врахувати при проектуванні даної
програмної системи, а відтак й висновок щодо актуальності даної роботи.

1.3. Функціональність програмної системи

Застосування механізму використання функцій – зручний спосіб опису можливостей
системи, що необхідно спроектувати. Оскільки, дозволяє з певним рівнем абстракції
здійснити опис її функціональності. Рекомендована кількість функцій, що дає повне
уявлення щодо проектованої системи – 25-99, проте бажано, щоб їх кількість не
перевищувала 50. Після того як всі функції перелічені та описані можна приступити до
прийняття рішень типу «відкласти до наступної версії», «реалізувати негайно», «повністю
відкинути» чи «додатково дослідити». Даний процес коректування масштабу необхідно
проводити на рівні функцій, а не на рівні вимог, щоб не «загрузнути» в деталях.
З метою кращої роботи з даною інформацією існує поняття атрибутів функції -
елементів даних, які забезпечать додаткову інформацію про кожну функцію.
Таблиця 1. Атрибути функцій
Атрибут Опис (значення функції)
Пропонована
Статус (визначення кінцевого варіанту затвердження функції) Затверджувана
Включена
Критична
Пріоритет (важливість функції) Важлива
Корисна
Низький рівень
Трудоємність (складність реалізації функції) Середній рівень
Високий рівень
Ризик (ймовірність того, реалізація функції викличе небажані Високий
наслідки, такі як збільшення витра, зміна графіку реалізації Середній
тощо) Низький
Висока
Стабільність (ймовірність того, що дана функція буде
Середня
змінюватися з часом)
Низька
Цільова версія (вказання версії продукту, в якій вперше
Номер версії
з’явиться реалізація функції)
Призначення (коментарі для розробників, що покращують
Коментар
ступінь розуміння розробки)
 Перший розділ необхідно закінчити коротким резюме стосовно необхідності
проведення досліджень у даній галузі, яке повинне містити висновок і формулюванням мети
власних досліджень, загальні підсумки наведених наукових даних і з проставлянням
наголосу на актуальності питань, які потребують вирішення і є предметом роботи.

2. ПРОЕКТУВАННЯ СИСТЕМИ
2.1. Опис системних вимог згідно з методологією Rational Unified Process
В даному підрозділі необхідно розробити розгорнутий текстовий опис основних
системних вимог згідно із варіантом курсового проекту.
RUP є результатом об’єднання підходів Rational Approach та Objectory Process, яке
відбулося після злиття у 1995 році компаній Rational Software і Objectory AB (створеної
Іваром Якобсоном). Можна також стверджувати, що RUP поєднує в собі найбільш позитивні
риси інших методологій проектування, зокрема таких як каскадна та спіральна моделі
життєвого циклу розробки ПЗ. Основним принципом RUP є принцип ітеративної розробки
(iterative development), в рамках якої розробка ведеться у вигляді короткочасних міні-
проектів фіксованої тривалості (наприклад по 4 тижні), які називаються ітераціями (iteration).
Кожна ітерація складається із власних фаз аналізу вимог, проектування, реалізації,
тестування, інтеграції та створенням робочої системи. Такий ітеративний цикл базується на
постійному розширенні і доповненні програмної системи в процесі кількох ітерацій з
періодичним зворотнім зв’язком і адаптацією додаткових компонентів до існуючого ядра
програмної системи (ПС), що розробляється.
RUP передбачає виконання різних видів діяльності, наприклад опис прецедентів в
рамках визначених дисциплін (disciplines), які називаються технологічними процесами
(workflow). Дисципліна – це набір видів діяльності та пов’язаних з ними артефактів в рамках
одного етапу, наприклад аналізу вимог. Артефакт (artifact) – будь-який результат виконання
певних дій по розробці ПС: текстова документація, занотовані системні вимоги, програмний
код, графічне зображення, схема БД, тощо.

Текстовий формат специфікація системних вимог

В контексті методології RUP системні вимоги (СВ) - це весь набір певних прецедентів
використання ПЗ, тобто концептуальна модель функціонування системи та її оточення.
Прецедент (Use Case) – це набір взаємопов’язаних сценаріїв, який описує
використання ПС певним актором для вирішення однієї із задач. Актор (Actor) - сутність, яка
має поведінку: напр., людина (користувач), окремий програмний компонент або інша
програмна система.
 Сценарій (Scenario) – послідовність дій або взаємодій між актором та ПС.
Первинною формою опису прецедентів є текст, який має бути сформованим у процесі
виявлення СВ (шляхом спілкування із майбутніми користувачами, експертами із предметної
області тощо). Для подальшої формалізації (структуризації) текстового опису прецедентів
існує декілька форм:
• вільна форма опису – неформальний стиль описання. Опис прецеденту займає
кілька абзаців і охоплює різні можливі сценарії;
• стислий опис – анотація у вигляді одного абзацу. Вона описує тільки головний
успішний сценарій;
• розгорнутий опис – при такому підході детально описуються всі кроки і
варіанти розвитку сценарію.
Найбільш інформативним та корисним для подальшого використання СВ в
проектуванні ПС є розгорнутий опис прецедентів. Він має наступний формат, який ми
розглянемо на прикладі розробки ПС для оформлення продажів товару в деякому
супермаркеті.
Приклад опису розгорнутого сценарію прецеденту за стандартом RUP
1) Зацікавлені особи прецеденту та їх вимоги: в цій секції опису подається, що
повинна зробити ПС для усіх можливих учасників процесу.
• Касир: повинен точно і швидко обробити дані щодо покупки кожного покупця.
• Покупець: хоче швидко оформити свою покупку з мінімальними витратами часу.
• Керівництво супермаркету: хоче мати повну інформацію щодо всіх транзакцій
касира та покупців.
• …
2) Користувач ПС тобто основний актор цього прецеденту: це касир супермаркету,
який працює із покупцями за допомогою ПС, що має бути розроблена.
3) Передумови прецеденту (preconditions): це перелік подій які завжди повинні
виконуватися до початку сценарію поточного прецеденту. Передумови не перевіряються у
даному сценарії прецеденту, вони вважаються результатом успішного виконанням деякого
іншого прецеденту. Наприклад, це можуть бути наступні умови
• ПС має бути активною
• Касир повинен успішно пройти процедуру аутентифікації в ПС
• …..
4) Основний успішний сценарій: ця секція специфікації описує «сценарій успіху».
Тобто дії що призводять до успішного завершення подій в основному процесі, наприклад:
1) Касир починає оформлення нового продажу при наявності запиту певного покупця;
 2) Касир вводить ідентифікатор поточного товару із переліку покупця
3) …
5) Розширення основного сценарію або альтернативні потоки: у цій секції вказуються
всі інші можливі варіанти розвитку подій в ПС, які призводять до успішного завершення
основного сценарію або альтернативні сценарії, що приводять до некоректного завершення
прецеденту. При цьому після виконання обробки усіх можливих розширень прецеденту ПС
повинна забезпечити повернення користувача в основний сценарій, якщо в ПС не
передбачено альтернативний хід подій. Наприклад, розширення основного сценарію:
Неправильний ідентифікатор товару
1. ПС повідомляє касира про помилку і відміняє ввід даних щодо поточного товару.
2. У разі необхідності касир може запросити у ПС і отримати (як підказку) весь список
можливих назв товарів та їх ідентифікаторів.
3. Касир повторно вводить коректний ідентифікатор товару.
4. ПС підраховує та відображає оновлену проміжну вартість поточного продажу (це є
точка повернення в основній сценарій).
6) Пост-умови (postconditions): це перелік умов, які завжди повинні виконуватися у
випадку успішного виконання основного сценарію (тобто коли задовольняються інтереси
усіх зацікавлених осіб із п.2), наприклад.
• дані щодо продажу оброблені та збережені в ПС,
• роздруковано потрібний чек,
• транзакція успішно зафіксована в базі даних ПС,
• …………………….
7) Спеціальні СВ: ця секція опису містить перелік нефункціональних вимог, атрибутів
якості або певних обмеження в функціонування ПС, що є пов’язаними із даним прецедентом.
Наприклад, це може бути:
• Необхідно забезпечити 100% надійність обробки всіх транзакцій,
• Потрібно забезпечити можливість локалізації інтерфейсу користувача ПС
• (тобто підтримка багатомовності діалогу з ПС);
• …
8) Список необхідних технологій та додаткових пристроїв: типовим прикладом
можуть бути технічні вимоги, які висувають зацікавлені особи для технологій вводу/виводу
даних тощо.
• ПС має бути розроблена як Web-орієнтована система;
• ідентифікатор товару зчитується із штрих-коду лазерним сканером;
• для користувача має бути використано сенсорний екран монітора;
 • …….
Типовим прикладом можуть бути технічні вимоги, які не висувають зацікавлені особи
для технологій вводу/виводу даних в ПС.

2.2. Деталізація функцій та аналіз категорій користувачів

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

2.2.1. Діаграма варіантів використання (use case diagram)

Діаграма варіантів використання (прецедентів), є вихідним концептуальним поданням
системи, що дозволяє:
• визначити спільні межі та контекст модельованого програмного забезпечення;
• сформулювати загальні вимоги до функціональної поведінки проектованої системи;
• розробляти вихідну концептуальну модель системи для її подальшої деталізації у
формі логічних і фізичних моделей;
• підготувати вихідну документацію для взаємодії розробників системи із замовниками
та користувачами.
Основними елементами і поняттями, пов'язаними з діаграмою варіантів використання
є: варіант використання (прецедент, Use Case), дійова особа (Actor), інтерфейс, відношення
асоціації, розширення, узагальнення та включення.

2.2.2. Діаграма класів (class diagram)

Служить для відображення статичної структури моделі системи в термінології класів
об'єктно-орієнтованого програмування. Діаграма класів є різновидом графу, вершинами
якого є елементи типу «класифікатор», які пов'язані різними типами структурних відношень.
Необхідно зауважити, що діаграма класів може також містити інтерфейси, пакети,
відношення і навіть окремі екземпляри, наприклад, об'єкти та зв'язки. Загалом дана діаграма
являє собою статичну структурну модель проектованої системи яку прийнято вважати
графічним представленням таких структурних взаємозв'язків логічної моделі системи, що не
залежать або інваріантні від часу. Діаграма класів складається з множини елементів, які в
сукупності відображають декларативні знання про предметну область. Вони інтерпретуються
в таких базових поняттях мови UML, як класи, інтерфейси і відношення між ними та їх
складовими компонентами. При цьому окремі компоненти цієї діаграми можуть утворювати
пакети для відображення більш загальної моделі системи. Якщо діаграма класів є частиною
деякого пакету, то її компоненти повинні відповідати елементам цього пакета, включаючи
можливі посилання на елементи з інших пакетів.

2.2.3. Діаграми кооперації (collaboration diagram)

Поняття кооперації (collaboration) є одним з фундаментальних понять у мові UML.
Воно служить для позначення множини взаємодіючих з певною метою об'єктів в загальному
контексті модельованої системи. Мета самої кооперації полягає в тому, щоб специфікувати
особливості реалізації окремих найбільш значущих операцій в системі. Кооперація визначає
структуру поведінки системи в термінах взаємодії учасників цієї кооперації. Діаграма
кооперації насамперед відображає структуру взаємодії та містить такі елементи:
• екземпляри акторів і класів, що беруть участь в реалізації варіанту використання;
• асоціацію між екземплярами акторів і класів;
• повідомлення, що передаються між екземплярами акторів і класів.
Кооперація може бути представлена на двох рівнях:
• рівні специфікації - показує ролі класифікаторів та асоціацій у взаємодії;
• рівні прикладів - вказує екземпляри і зв'язки, що утворюють окремі ролі в кооперації.
Головна особливість діаграми кооперації полягає в можливості графічно представити
не тільки послідовність взаємодії, але й усі структурні відношення між об'єктами, які беруть
участь у цій взаємодії.

2.2.4. Діаграма послідовності (sequence diagram)

Діаграма послідовності використовується для представлення часових особливостей
передачі і прийому повідомлень між об'єктами. Вони дозволяють наочно показати сценарії
варіантів використання проектованої системи. На діаграмі послідовності зображуються
виключно ті об'єкти, які безпосередньо беруть участь у взаємодії і не показуються можливі
статичні асоціації з іншими об'єктами. Для неї ключовим моментом є власне динаміка
взаємодії об'єктів в часі. При цьому, діаграма послідовності має ніби два виміри.
Перший - зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію
життя окремого об'єкта, який бере участь у взаємодії. Графічно кожний об'єкт зображується
прямокутником і розташовується в верхній частині своєї лінії життя. Всередині
прямокутника записується з підкресленням ім'я об'єкта та ім'я класу, що розділені
двокрапкою. Підкреслення служить ознакою об'єкта, який, як відомо, являє собою екземпляр
класу. Не виключається ситуація, коли ім'я об'єкта може бути відсутнім на діаграмі
послідовності. У цьому випадку вказується тільки ім'я класу, а сам об'єкт вважається
анонімним. Крайнім зліва на діаграмі відображається об'єкт, що є ініціатором взаємодії.
Праворуч відображається інший об'єкт, який безпосередньо взаємодіє з першим. Таким
чином, всі об'єкти на діаграмі послідовності утворюють деякий порядок, який визначається
ступенем активності цих об'єктів при взаємодії один з одним.
Другий вимір діаграми послідовності – вертикальна часова вісь, спрямована зверху
вниз. Початковому моменту часу відповідає верхня частина діаграми. При цьому взаємодія
об'єктів реалізується за допомогою повідомлень, які надсилаються об’єктам. Повідомлення
відображаються у вигляді горизонтальних стрілок з назвою повідомлення і також утворюють
порядок за часом свого виникнення. Іншими словами, повідомлення, які розташовані на
діаграмі послідовності вище, ініціюються раніше тих, які розташовані нижче. При цьому
масштаб на вісі часу не вказується, оскільки діаграма послідовності моделює лише часову
впорядкованість взаємодії типу «раніше-пізніше».

2.2.5. Діаграма діяльності (activity diagram)

Візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу
станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по
завершенню дій. Дія є фундаментальною одиницею визначення поведінки в специфікації. Дія
отримує множину вхідних сигналів та перетворює їх на множину вихідних. Виконання дії
відповідає виконанню окремої дії. Подібно до цього, виконання діяльності є виконанням
окремої діяльності, буквально, включно із виконанням тих дій, що містяться в діяльності.
Кожна дія в діяльності може виконуватись один, два, або більше разів під час одного
виконання діяльності. Щонайменше, дії мають отримувати дані, перетворювати їх та
тестувати, деякі дії можуть вимагати певної послідовності. Специфікація діяльності (на
вищих рівнях сумісності) може дозволяти виконання декількох (логічних) потоків, та
існування механізмів синхронізації для гарантування виконання дій у вірному порядку.

2.2.6. Діаграма компонентів

Діаграма компонентів описує особливості фізичного подання системи. Вона дозволяє
визначити архітектуру системи, що проектується, встановивши залежності між програмними
компонентами, в роді яких може виступати початковий чи виконуваний код. У багатьох
середовищах розроблення модуль або компонент відповідає файлу. Пунктирні стрілки, що
з’єднують модулі, показують відношення взаємозалежності, аналогічні до тих які мають
місце при компіляції початкових текстів програм. Основними графічними елементами
діаграми компонентів є компоненти, інтерфейси і залежності між ними.
 Діаграма компонентів розробляється для таких цілей:
• візуалізації загальної структури початкового коду програмної системи;
• специфікації варіанту програмної системи;
• забезпечення багаторазового використання окремих фрагментів програмних кодів;
• подання концептуальної і фізичної схем баз даних.

Перелічені деталізовані діаграми повинні бути відображені в програмному засобі

IBM Rational Rose з наведенням деталізованого їх опису

3. ВИБІР ЗАСОБІВ РЕАЛІЗАЦІЇ ТА КОНСТРУЮВАННЯ СИСТЕМИ

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

3.2. Аналіз контрольного прикладу

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

Вимоги до оформлення електронної версії ПЗ

Розроблене програмне забезпечення повинно включати довідкову інформацію про
основні терміни, визначені тематикою роботи, і дані про особливості функціонування
програми. Розроблені програмні модулі повинні бути документованими, тобто тексти
програм повинні містити всі необхідні коментарі. Програмний код повинен бути виконаний
відповідно до правил «гарного стилю» і бути максимально оптимізований.

Вимоги до оформлення пояснювальної записки

Пояснювальна записка за змістом має відповідати завданню на курсову роботу.
Оформлення пояснювальних записок до курсових робіт здійснюється відповідно до вимог
ДСТУ 8302:2015 Інформація та документація. Бібліографічне посилання. Загальні положення
та правила складання». Пояснювальна записка виконується за допомогою текстового
процесору (MS Word, Writher (OpenOffice), WordPerfect, Word Pro або інші такого ж класу) та
графічних редакторів (VISIO, Corel Draw – у випадку технічних рисунків, Photoshop – для
растрової графіки). Для описання процесів функціонування як існуючої системи, так і
системи, що проектується, інформаційної бази, рекомендується використовувати нотації та
відповідні CASE-засоби. Пояснювальна записка оформляється на аркушах формату A4
(210297мм), які заповнюються з однієї сторони. Текст друкується на принтері. Заголовки
розділів можуть бути виділені великими літерами або шляхом підкреслення. Текст роботи
набирається без помилок українською мовою.
Текст на сторінці розміщується рівномірно з дотриманням відступів: зверху – 2,0 см,
знизу – 2,0 см, зліва – 2,0 см, справа – 1,0 см. При комп’ютерному наборі необхідно вибрати
шрифт Times New Roman Cyr, розмір шрифта –14, міжрядковий інтервал –1.5, вирівнювання
абзаців – по ширині, перший рядок – відступ 1 см..
Текст основної частини дипломної роботи поділяють на розділи, підрозділи, пункти
та підпункти. Заголовки структурних частин роботи «ЗМІСТ», «ВСТУП», «РОЗДІЛ»,
«ВИСНОВКИ», «СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ», «ДОДАТКИ» друкують великими
літерами симетрично до тексту. Заголовки підрозділів друкують маленькими літерами (крім
першої великої) з абзацного підступу. Крапку в кінці заголовка не ставлять. Якщо заголовок
складається з двох або більше речень, їх розділяють крапкою. Заголовки пунктів друкують
маленькими літерами (крім першої великої) з абзацного відступу в розрядці в підбір до
тексту. В кінці заголовка, надрукованого в підбір до тексту, ставиться крапка.
Кожну структурну частину (розділ) роботи треба починати з нової сторінки.
Нумерацію сторінок, розділів, підрозділів, пунктів, підпунктів, рисунків, таблиць, формул
подають арабськими цифрами без знака №. Першою сторінкою роботи є титульний аркуш.
На титульному аркуші номер сторінки не ставлять, на наступних сторінках номер
проставляють у правому верхньому куті сторінки без крапки в кінці.
Зміст, вступ, висновки, список використаних джерел не мають порядкового номера,
але всі аркуші, на яких розміщені згадані структурні частини роботи, нумерують звичайним
чином. Не нумерують лише їхні заголовки, тобто не можна друкувати «1.ВСТУП», або
«Розділ 9. ВИСНОВКИ».
Кожен розділ повинен мати свій номер, який записується перед його назвою. Номер
розділу ставлять після слова «РОЗДІЛ», після номера крапку не ставлять, потім з нового
рядка друкують заголовок розділу. Кожен розділ необхідно розпочинати з нової сторінки.
Розділ може складатися з підрозділів. Підрозділи нумерують у межах кожного розділу.
Номер підрозділу складається з номера розділу і порядкового номера підрозділу, між якими
ставлять крапку. У кінці номера підрозділу повинна стояти крапка, наприклад: ‘‘2.3.’’ (третій
підрозділ другого розділу). Потім у тому ж рядку йде заголовок підрозділу, наприклад: 2.1.
Опис предметної області. Пункти нумерують у межах кожного підрозділу. Номер пункту
складається з порядкових номерів розділу, підрозділу, пункту, між якими ставлять крапку. У
кінці номера повинна стояти крапка, наприклад: «1.3.2.» (другий пункт третього підрозділу
першого розділу). Потім у тому ж рядку розташовується заголовок пункту. Пункт може не
мати заголовка. Підпункти нумерують у межах кожного пункту за такими ж правилами, як
пункти. Ілюстрації (фотографії, креслення, схеми, графіки, карти) і таблиці необхідно
подавати у роботі безпосередньо після тексту, де вони згадані вперше, або на наступній
сторінці. Ілюстрації позначають словом «Рис.» і нумерують послідовно у межах розділу, за
винятком ілюстрацій, поданих у додатках. Номер ілюстрації повинен складатися з номера
розділу і порядкового номера ілюстрації, між якими ставиться крапка. Наприклад: Рис. 1.2
(другий рисунок першого розділу). Номер ілюстрації, її назва і пояснювальні підписи
розміщують послідовно під ілюстрацією. Якщо у роботі подано одну ілюстрацію, то її
нумерують за загальними правилами. Написи на рисунках виконуються шрифтом Times New
Roman (розмір – 14).
Рисунки підписують і нумерують під рисунком по центру тексту. Підписи під
рисунками виконують шрифтом Times New Roman Cyr (розмір – 14), курсив.
Таблиці нумерують послідовно (за винятком таблиць, поданих у додатках) у межах
розділу. У правому верхньому куті над відповідним заголовком таблиці розміщують напис
«Таблиця» із зазначенням її номера (шрифт – Times New Roman Cyr, розмір – 14, записується
курсивом). Номер таблиці повинен складатися з номера розділу і порядкового номера
таблиці, між якими ставиться крапка, наприклад: «Таблиця 1.2’’ (друга таблиця першого
розділу). Якщо у роботі одна таблиця, її нумерують за загальними правилами. При переносі
частини таблиці на інший аркуш (сторінку) слово «Таблиця» і номер її вказують один раз
справа над першою частиною таблиці, над іншими частинами пишуть слова «Продовження
табл.» і вказують номер таблиці, наприклад: «Продовження табл.1.2». Заголовок таблиці
розміщують по центру (шрифт – Times New Roman Cyr, розмір – 14, записується жирними
буквами). Розмір шрифту для набору текстів у таблицях – 13.
Формули у роботі (якщо їх більше одної) нумерують у межах розділу. Номер
формули складається з номера розділу і порядкового номери формули у розділі, між якими
ставлять крапку. Формули подають у форматі Equation. Номери формул пишуть біля
правого берега аркуша на рівні відповідної формули у круглих дужках, наприклад: (3.1)
(перша формула третього розділу).
 Список використаних джерел – елемент бібліографічного апарату, котрий містить
бібліографічні описи використаних джерел і розміщується після висновків.
Бібліографічний опис складають безпосередньо за друкованим твором або виписують з
каталогів і бібліографічних покажчиків повністю без пропусків будь-яких елементів,
скорочення назв тощо. Список літератури виконується згідно з вимогами стандартів.
Укладаючи списки літератури, посилаючись на інші видання, студент повинен керуватися
чинними новими стандартами бібліографічного опису, які розробила Книжкова палата
України. Треба при формуванні списку використовувати Національний стандарт України
«Інформація та документація. Бібліографічна посилання. Загальні положення та правила
складання. ДСТУ 8302:2015».
Зразки оформлення списків літератури:

КНИГИ
Однотомні видання
Один автор
Федорова Л. Д. З історії пам’яткоохоронної та музейної справи у Наддніпрянській
Україні. 1870-ті — 1910-ті рр. Київ, 2013. 373 с.
Два і більше авторів
Zhovinsky E.Ya., Kryuchenko N.O., Paparyha P.S. Geochemistry of Environmental Objects of
the Carpathian Biosphere Reserve. Kyiv, 2013. 100 p.
Людський розвиток в Україні: трансформація рівня життя та регіональні диспропорції: у
2-х т.: кол. моногр. Київ, 2012. 436 с.
Без автора
Збірник
Софія Київська: Візантія. Русь. Україна. Вип. ІІ. Київ, 2012. 464 с.
Матеріали конференцій, з’їздів, тези доповідей
Физика импульсных разрядов в конденсированных средах. Материалы ХVI
Международной научной конференции (19—22 авг. 2013, г. Николаев). Николаев, 2013.
253 с.

Багатотомні видання
Видання загалом
Енциклопедія історії України: у 10 т. Київ: Наук. думка, 2013. Т. 10. 784 с.
Окремий том
Dark energy and dark matter in the Universe. In three vol. Vol. 3. Dark matter: Observational
manifestation and experimental searches. Kyiv: Akademperiodyka, 2015. 356 p.
Серіальні та продовжувані видання
Газета
Світ: всеукр. тижн. / засн.: Мін-во освіти і науки України, Нац. акад. наук України. 1997,
квітень — . Київ. Щотиж.
1997, № 1—5.
Журнал
Вісник Національної академії наук України: загальнонаук. журн. / засн.: Нац. акад. наук
України. 1928, жовтень — . Київ. Щоміс.
2016, № 1—12.
Бюлетень
Бюлетень Міністерства юстиції України : наук. журн. / засн.: Мін-во юст. України. 1999—
. Київ. Щоміс.
2016, № 6, 24 с.
Продовжуваний збірник
Наука України у світовому інформаційному просторі: серія / засн.: Нац. акад. наук
України. 2008— . Київ: Академперіодика.

ІНШІ ВИДАННЯ
Законодавчий матеріал
Про видавничу справу: Закон України від 05.06.1997 № 318/97-ВР. Київ: Парламентське
видавництво, 2015. 24 с.
Правила
Правила пожежної безпеки в Україні. Затв. Мін-вом внутріш. справ України
30.12.2014. Чинний від 10.04.2015. Київ: Техніка, 2003. 157 с.
Збірник стандартів
Правила учета электрической энергии: сб. основных норматив.-техн. док., действующих в
обл. учета электроэнергии. Москва, 2002. 366 с.
Окремий стандарт
ДСТУ 3017-2015. Видання. Основні види. Терміни та визначення. Київ, 2016. 42с.
Авторське свідоцтво
А. с. 1810306 СССР, МКИ5 С 02 F 1/469. Способ деминерализации водных расворов / В.Д.
Гребенюк, Н.П. Стрижак, В.В. Гончарук, А.О. Самсони-Тодоров, А.В. Гречко. № 4934753;
заявл. 08.05.91; опубл. 23.04.93, Бюл. № 15.
Патент
Пат. КМ 98077 Україна. Спосіб одержання йодиду цезію або йодиду натрію для
вирощування монокристалів. Опубл. 10.04.2015.
Заявка
Заявка u 2014 06343 Україна, МПК (2014.04) B01J 13/00. Спосіб отримання колоїдного
розчину наночасток срібла / О.А. Півоваров, М.І. Воробйова (Україна); заявник та
патентовласник ДВНЗ "Укр. держ. хім.-технол. ун-т". № u 2014 06343; заявл. 10.06.14.
Каталог
Національна академія наук України. Анотований каталог книжкових видань 2008 року
Київ: Академперіодика, 2009. 444 с.
Препринт
Панасюк М. І., Скорбун А. Д., Сплошной Б. М. Про точність визначення активності
твердих радіоактивних відходів гамма-методами. Чорнобиль: Ін-т пробл. безпеки АЕС
НАН України, 2006. 7, [1] с. (Препринт. НАН України, Ін-т пробл. безпеки АЕС; 06-1).
Автореферат дисертації
Старовойт С. В. Видавнича діяльність Національної академії наук України у 1918—1933
рр. : автореф. дис. ... канд. іст. наук. Київ, 2003. 20 с.

ЧАСТИНА ВИДАННЯ
Стаття із журналу, збірника, розділ книги
Незалежно від кількості авторів у позатекстовому переліку бібліографічних посилань
(списку літератури)
Яцків Я. С., Радченко А. І. Про ефективність видання наукових журналів в Україні. Вісн.
НАН України. 2012. № 6. С. 62—67.
Назарчук З. Т. Дифракция Е-поляризованных электромагнитных волн на цилиндрическом
экране с сечением в виде ломаной кривой. Волны и дифракция. Тбилиси, 1985. Кн. 1. С.
507—511.
Скальський В. Р. Становлення методу акустичної емісії в установах Західного наукового
центру. Теорія і практика раціон. проектування, виготовлення і експлуатації машинобуд.
конструкцій: Праці 2 міжнар. наук.-техн. конф. (Львів, 11—13 лист. 2010). Львів, 2010. С.
9—10.
Рецензія
Касьянов Г. Глобальна еволюція людства: культурно-цивілізаційний вимір. Вісн. Кн.
палати. 2001. № 12. С. 14–15.
Рец. на кн.: Шейко В. Культура. Цивілізація. Глобалізація (кінець XIX — початок XX ст.):
монографія: у 2 т. Харків, 2001. Т. 1. 520 с. ; т. 2. 400 с.

ЕЛЕКТРОННІ РЕСУРСИ ВІДДАЛЕНОГО ДОСТУПУ

Опис ресурсу загалом
Наукові публікації і видавнича діяльність НАН України. Київ, 2007. URL:
http://www.nas.gov.ua/publications (дата звернення: 19.03.2014).
Опис частини електронного ресурсу у позатекстовому переліку бібліографічних
посилань (списку літератури)
Garfield E. More on the ethics of scientific publication: abuses of authorship attribution and
citation amnesia undermine the reward system of science. Essays of an information scientist.
URL: http://www.garfield.library.upenn.edu/essays/v5p621y1981-82.pdf (Last accessed:
16.04.2013).

НЕОПУБЛІКОВАНІ ВИДАННЯ
Звіт про науково-дослідну роботу
Розвиток науково-видавничої справи на початковому та сучасному етапах діяльності
Національної академії наук України: звіт про НДР (заключний) ВД "Академперіодика"
НАН України; кер. Я. С. Яцків. Київ, 2015. 112 с. № ДР 0113U001213.
Дисертації
Воскобойнікова-Гузєва О.В. Бібліотечно-інформаційна сфера України в контексті
соціальних трансформацій кінця ХХ ст. – 10-х років ХХІ ст.: концепції стратегічного
розвитку, динаміка змін, перспективи: дис. ... д-ра наук із соц. комунік.: 27.00.03 / Нац. б-
ка України ім. В.І. Вернадського. Київ, 2014.
Депоновані наукові роботи
Тріщ Б.М. Оптимізація температурних полів і напружень у квадратній пластині з отвором
/ ЛНУ ім. Івана Франка. Львів, 2001. 14 с. Деп. в ДНТБ України 11.12.01, № 239.
Літературу можна розміщуватиа за алфавітом або у порядку посилання на неї. У списку
можна наводити тільки ту літературу, яку було використано під час виконання роботи і на
яку є посилання у тесті пояснювальної записки. За використання Internet-джерел обов’язково
вказувати повну назву роботи, її дату та WEB-адресу. У випадку цитування фрагментів
роботи відповідний фрагмент беруть у лапки, і за посилання, окрім літературного джерела,
вказують також сторінку, на якій знаходиться цитата в першоджерелі.
Посилання у тексті роботи на джерела треба зазначати порядковим номером за
переліком посилань, виділеним двома квадратними дужками, наприклад, “... у працях [62, 64,
65, 75, 84, 101]...’’.

Захист курсової роботи

Закінчена та оформлена пояснювальна записка та електронна версія курсової роботи
повинна бути представлена керівнику курсового проектування в термін, зазначений у
технічному завданні. Керівник роботи перевіряє правильність роботи програмного додатку
та оформлення пояснювальної записки. На захист студент повинен подати такі документи:
пояснювальну записку (в друкованому та електронному виді); електронну версію
розробленого програмного продукту (вихідний і завантажувальний модуль) на компакт-
диску та залікову книжку.
Типовий план доповіді: обґрунтування вибору теми, її актуальність; постановка
задачі; вихідні дані; загальний підхід до вирішення завдання та його обґрунтування; методи
вирішення завдань; основні результати та технічні характеристики розробки; стан розробки в
момент закінчення проекту; перспективи впровадження; перспективи подальших робіт у
даному напрямку; висновки по роботі. По закінченню доповіді студент дає відповіді на
поставлені завдання та отримує оцінку від керівника курсового проекту.

Теми завдань для курсової роботи

1. Інформаційна система обліку трафіку користувачів інтернету
2. Інформаційна система управління проектами в галузі програмного забезпечення
3. Інформаційна система аналізу виставкової діяльності у м.Львів
4. Інформаційна система прийняття рішень для розв'язання стратегічних проблем
5. Інформаційна система керування автодилерською мережею
6. Інформаційна система прийняття рішень діяльності фірми з продажу меблів
7. Інформаційна система аналізу надійності роботи веб-сервера
8. Інформаційна система обліку купівлі-продажу земельних ділянок
9. Інформаційна система діяльності автомобільного салону
10. Інформаційна система прийняття рішень в галузі медичної генетики
11. Інформаційна система підтримки прийняття рішень в туристичній сфері
12. Інформаційна система визначення рейтингу науково-педагогічних працівників
13. Інформаційна система прийняття рішень з розміщення товарів у відповідності до
споживчого кошика
14. Інформаційна система мереж аптек у місті Львові
15. Інформаційна система формування особистісно-орієнтованого контенту
16. Інформаційна система обліку навчального навантаження академічних груп
17. Інформаційна система автоматизації руху транспорту в місті Львів
18. Інформаційна система аналізу ринку нерухомості
19. Інформаційна система опису діяльності працівників маркетингового відділу
компанії
20. Інформаційна система визначення на аналізу рівня підготовленості студента
21. Інформаційна система аналізу лотів на інтернет-аукціонах
22. Інформаційна система прийняття рішень в ріелтерському бізнесі
23. Інформаційна система обліку та аналізу навчального навантаження викладача
24. Інформаційна система екскурсійно-туристичної діяльності
25. Інформаційна система контролю сервісів, що надаються користувачу в Інтернет
26. Інформаційна система автоматизованої мережі документообліку на підприємстві
27. Інформаційна система прийняття рішень в галузі медичної генетики
28. Інформаційна система оцінювання знань студентів у ВНЗ
29. Інформаційна система з оцінки кредитоспроможності клієнта банку
30. Інформаційна система аналізу захищеності мережі Інтернет
31. Інформаційна система прийняття маркетингових рішень
32. Інформаційна система пошуку однакових зображень.
33. Інформаційна система управління діяльністю магазину
34. Інформаційна система вибору автопрокатного підприємства
35. Інформаційна система організації процесу тренувань в тренажерному залі
36. Інформаційна система розрахунку рентабельності інтернет-магазину
37. Інформаційна система визначення ступеню співпадіння текстів
38. Інформаційна система визначення оптимальних фізичних характеристик та
раціону людини
39. Інформаційна система тифлокоментарування сюжету для людей з вадами зору.
40. Інформаційна система обліку та реалізації товарів магазину єдиноборств
41. Інформаційна система аналізу діяльності архітектурно-будівельної компанії
42. Інформаційна система організації відпочинку туристичною фірмою
43. Інформаційна система автоматизації обліку квитків
44. Інформаційна система автоматизації процесів галузі працевлаштування
45. Інформаційна система організації виробництва тортів і тістечок
46. Інформаційна система з вибору мобільних пристроїв
47. Інформаційна системи оцінювання знань учнів та підтримки прийняття рішень
щодо вибору вищих навчальних закладів
48. Інформаційна система визначення жанру пісні
49. Інформаційна система складання кошторису ремонтних робіт
50. Інформаційна система керування аудиторним фондом кафедри
51. Інформаційна система аналізу виконання завдань ІТ-проектів
52. Інформаційна система підбору оптимальної конфігурації комп'ютера
53. Інформаційна система з вибору автомобілів.
54. Інформаційна система автоматизації роботи дошкільного навчального закладу
55. Інформаційна система аналізу фінансово-економічного стану підприємства
56. Інформаційна система дистанційного спостереження за об’єктами охорони
57. Інформаційна система обліку та прогнозування витрат матеріальних ресурсів
58. Інформаційна система обліку навчальних приміщень університету
59. Інформаційна система формування кошторису на будівництві
60. Інформаційна система аналізу контенту інтернет ресурсу
61. Інформаційна система аналізу гіпертекстових документів в з метою
автоматизованого збору даних
62. Інформаційна система розміщення товарів у відповідності до споживчого кошика
63. Інформаційна система мереж аптек у місті Львові
64. Інформаційна система з надання телекомунікаційних послуг
65. Інформаційна система складання кошторису ремонтних робіт
66. Інформаційна система аналізу виконання завдань ІТ-проектів
67. Інформаційна система нарахування заробітної плати
68. Інформаційна система автоматизації роботи дошкільного навчального закладу
69. Інформаційна система дистанційного спостереження за об’єктами охорони
70. Інформаційна система пошуку однакових зображень.
71. Інформаційна система управління діяльністю магазину
72. Інформаційна система організації процесу тренувань в тренажерному залі
73. Інформаційна система дистанційного моніторингу кліматичних умов
74. Інформаційна система автоматизації роботи навчального центру
75. Інформаційна система діяльності роботи банку з цінними паперами
76. Інформаційна система дистанційного вивчення іноземних мов
77. Інформаційна система для організації інтерактивних промо-акцій
78. Інформаційна система прийняття маркетингових рішень
79. Інформаційна система пошуку однакових зображень.
80. Інформаційна система автоматизації процесів галузі працевлаштування
81. Інформаційна система організації виробництва тортів і тістечок
82. Інформаційна система з вибору мобільних пристроїв
83. Інформаційна система діагностики в стоматології
84. Інформаційна система моніторингу руху громадських транспортних засобів
85. Інформаційна система вибору медпрепаратів
86. Інформаційна система відслідковування помилок програмного забезпечення
87. Інформаційна система геолокації на території
88. Інформаційна система обліку навчального навантаження академічних груп
89. Інформаційна система автоматизації руху транспорту в місті Львів
90. Інформаційна система аналізу ринку нерухомості
 Література
1. Литвин В.В. Проектування інформаційних систем /Н. Б. Шаховська, В. В. Литвин -
Львів: "Магнолія-2006". - 380 с.
2. Пономаренко В.С. Проектування інформаційних систем : посібник / В.С.
Пономаренко, О.І. Пушкар, І.В. Журавльова, С.В. Мінухін - К. : Академія, 2012. –
488 с.
3. Марченко А.В. Проектування інформаційних систем: навч.посібник / А.В. Марченко.
- Київ, вид-во КНЕУ, 2016. - 250 с.
4. Недашківський О.М. Планування та проектування інформаційних систем:навч.
посібник/ О.М. Недашківський. - Київ, 2014. - 215 с.
5. Hassan Gomaa. Software Modeling and Design: UML, Use Cases, Patterns, and Software
Architectures. - Cambridge University Press, 2011. - 578 p.
6. Bernhard Rumpe. Modeling with UML: Language, Concepts, Methods. - Springer
International Publishing, 2016. - 288 p
7. Bhuvan Unhelkar. Software Engineering with UML. - Auerbach Publications, CRC PRESS,
2018. - 427 p.
 Додаток А
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ „ЛЬВІВСЬКА ПОЛІТЕХНІКА”

Кафедра ІСМ

КУРСОВА РОБОТА
з дисципліни «Методології проектування інформаційних систем »
НА ТЕМУ:

«ТЕМА РОБОТИ»

Виконав студент групи ІТ-%% Прізвище Ініціали

Оцінка Балів Дата
Номер залікової книжки
%%%%%%%

Керівник проекту %%%%%%%%%%%%%%%%

Львів 202%
 ЗАВДАННЯ ТА КАЛЕНДАРНИЙ ПЛАН ВИКОНАННЯ

Завдання до виконання Дата

Анотація
Вступ
Розділ 1. Аналіз літературних джерел та предметної галузі
1.1. Основні засади дослідження
1.2. Аналіз відомих засобів вирішення проблеми
1.3. Функціональність програмної системи
Висновок до першого розділу
Розділ 2. Проектування системи
2.1. Опис системних вимог згідно з методологією RUP
2.2. Деталізація функцій та аналіз категорій користувачів
2.2.1. Діаграма варіантів використання
2.2.2. Діаграма класів
2.2.3. Діаграми кооперації
2.2.4. Діаграма послідовності
2.2.5. Діаграма діяльності
2.2.6. Діаграма компонентів
Висновок до другого розділу
Розділ 3. Вибір засобів реалізації та конструювання системи
3.1. Вибір програмного рішення
3.2. Аналіз контрольного прикладу
Висновок до третього розділу
Висновки
Список використаних джерел
Додатки

Завдання прийнято до виконання ___________________ Прізвище Ініціали

(підпис студента)

Керівник проекту %%%%%%%%%%%%%%%%