47255

Автоматизовані системи управління

Книга

Информатика, кибернетика и программирование

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

Украинкский

2013-11-27

391.5 KB

3 чел.

PAGE  1

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

ДОНЕЦЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

МЕТОДИЧНІ ВКАЗІВКИ

ДО ДИПЛОМНОГО ПРОЕКТУВАННЯ

для студентів спеціальності 7.080401 Інформаційні

управляючі системи і технології (ІУС)

Донецьк – ДонНТУ – 2006


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

ДОНЕЦЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

Кафедра "Автоматизовані системи управління"

МЕТОДИЧНІ ВКАЗІВКИ

ДО ДИПЛОМНОГО ПРОЕКТУВАННЯ

для студентів спеціальності 7.080401 Інформаційні

управляючі системи і технології (ІУС)

                                                         Розглянуто на засіданні  кафедри

                                                        “Автоматизовані системи управління”,

                                                         протокол № 2 від 11.10. 2006 р.

                                                         Затверджено на засіданні

                                                          учбово–видавничої ради ДонНТУ,

                                                          протокол № 11  від 06.12.2006 р.

Донецьк – ДонНТУ – 2006

УДК 658.567

Методичні вказівки до дипломного проектування для студентів спеціальності 7.080401 “Інформаційні управляючі системи і технології”(ІУС)/ Спорихін В. Я.,Лаздинь С. В., Жукова Т. П., Шатохін П. О., Блощицький В. П. – Донецьк: ДонНТУ, 2006. – 64 с.

Методичні вказівки містять вимоги до структури й  змісту дипломного проекту за спеціальністю 7.080401 Інформаційні управляючі системи і технології”. Викладено вимоги й правила щодо оформлення пояснювальної записки і графічної частини дипломного проекту. Дано рекомендації з виконання окремих розділів дипломного проекту. Розглянуто організаційні питання дипломного проектування і захисту дипломних проектів перед державною екзаменаційною комісією.  

Укладачі: Спорихін В. Я., професор

                    Лаздинь С.В., професор

                    Жукова Т.П., доцент

                    Шатохін П.О., доцент

                    Блощицький В.П., ст. викл.

Рецензенти:  Ярошенко М.О., доцент

                     Зорі О.А., доцент

Відповідальний за випуск: Скобцов Ю.О., професор

З М І С Т

ПЕРЕЛІК УМОВНИХ ПОЗНАЧОК І СКОРОЧЕНЬ. . . . . . . . . . . . . . . . . . . . .

4

ВСТУП . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . .

5

1

ОРГАНІЗАЦІЯ ДИПЛОМНОГО ПРОЕКТУВАННЯ . . . . . . . . . . . . . . . .

6

2

ВИМОГИ ДО СТРУКТУРИ ДИПЛОМНОГО ПРОЕКТУ . . . . . . . . . . . . .

10

2.1 Структура дипломного проекту . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2 Вимоги до структурних елементів вступної частини . . . . . . . . . . . .

11

2.3 Вимоги до структурних елементів основної частини . . . . . . . . . . . .

13

2.4 Рекомендований зміст дипломного проекту . . . . . . . . . . . . . . . . . . . . .

14

3

РЕКОМЕНДАЦІЇ З ВИКОНАННЯ ОКРЕМИХ РОЗДІЛІВ ДИПЛОМНОГО ПРОЕКТУ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.1 Рекомендації з розробки технічного завдання. . . . . . . . . . . . . . . . . . .

17

3.2 Рекомендації з розробки функціональної структури . . . . . . . . . . . . . .  

24

3.3 Рекомендації з розробки інформаційного забезпечення . . . . . .

25

3.4 Рекомендації з розробки математичного забезпечення . . . . . . .

32

3.5 Рекомендації з розробки програмного забезпечення . . . . . . . . . . . . . .

34

3.6 Рекомендації з розробки технічного забезпечення . . . . . . . . . . . . . . . .

36

3.7 Рекомендації з розробки комп'ютерної мережі . . . . . . . . . . . . . . . . . . .   

39

3.8 Рекомендації з тестування підсистеми . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4

ВИМОГИ ДО ОФОРМЛЕННЯ ДИПЛОМНОГО ПРОЕКТУ

42

4.1 Загальні вимоги. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.2 Оформлення ілюстрацій . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.3 Оформлення таблиць . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.4 Оформлення формул і рівнянь . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.5 Оформлення переліків. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.6 Оформлення посилань. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.7 Оформлення додатків . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.8 Вимоги до складу й оформлення графічної частини

49

5

ОРГАНІЗАЦІЯ ЗАХИСТУ ДИПЛОМНИХ ПРОЕКТІВ ПЕРЕДУ ДЕК. .

52

5.1 Подання дипломного проекту до захисту . . . . . . . . . . . . . . . . . . .

52

5.2 Вимоги до змісту відгуку керівника та рецензії . . . . . . . . . . . . . . . . . .

53

5.2.1 Зміст відгуку керівника проекту . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.2.2 Зміст рецензії на  дипломний проект. . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.3 Захист дипломних проектів перед ДЕК . . . . . . . . . . . . . . . . . . . . . . . . .

54

ПЕРЕЛІК ПОСИЛАНЬ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  .

58

Додаток А Форма першої сторінки обкладинки . . . . . . . . . . . . . . . . . . . . . .

59

Додаток Б Форма титульного листа пояснювальної записки . . . . . . . .

60

Додаток В Форма листа завдання з календарним планом . . . . . . . . . . . .

61

Додаток Д Форма відомості обсягу дипломного проекту . . . . . . . . . .

63

Додаток Е Приклади бібліографічного опису посилань . . . . . . . .

64


ПЕРЕЛІК УМОВНИХ ПОЗНАЧОК І СКОРОЧЕНЬ

АС – автоматизована  система

АСУТП –автоматизована  система управління технологічними процесами

БД –бази даних

ДЕК– державна екзаменаційна комісія

доц. –доцент

ДП – дипломний проект

ІУС –інформаційні управляючі системи і технології

КМ–комп'ютерна мережа

КП –комп’ютеризована підсистема

МЗ –математичне забезпечення

ОС –операційна система

ПЗ –пояснювальна записка

ПК –персональний комп’ютер

ПП –периферійні пристрої

ПрЗ –програмне забезпечення

Рис. – рисунок

СУБД система управління базами даних

Табл. таблиця

ТехЗ –технічне забезпечення

ТЗ –технічне завдання

ВСТУП

Дипломне проектування є завершальним етапом підготовки спеціаліста, на якому студенти мають можливість застосувати отримані знання.

У процесі дипломного проектування і захисту дипломного проекту (ДП) студент повинен показати свою підготовку із загальнотеоретичних і спеціальних дисциплін, уміння користуватися науково–технічною, економічною літературою, стандартами. На етапі дипломного проектування і захисту ДП проявляється професійна зрілість майбутнього фахівця.

Методичні вказівки містять вимоги до структури,  змісту і оформлення ДП за фахом 7.080401 "Інформаційні управляючі системи і технології" (ІУС). Викладено рекомендації з виконання окремих розділів дипломного проекту. Розглянуто організаційні питання дипломного проектування й захисту дипломних проектів перед державною екзаменаційною комісією (ДЕК).

При розробці методичних вказівок були використані нормативні документи:

  •  стандарти на створення автоматизованих систем [1–3];
  •  інструктивні і методичні документи Міністерства освіти і науки України [4–6];
  •  стандарти різних рівнів на оформлення  документації [7–9];  
  •  наскрізна програма практик для студентів спеціальності ІУС [10].

У методичних вказівках також використані матеріали, надані викладачами кафедри АСУ доц. Світличною В.А. (підрозділ 3.4) та доц. Приваловим М.В. (підрозділ 3.7).

1 ОРГАНІЗАЦІЯ ДИПЛОМНОГО ПРОЕКТУВАННЯ

Теми дипломних проектів затверджуються наказом ректора університету. Підставою для наказу є заява студента на ім'я декана факультету про закріплення теми ДП та дати захисту. Заява попередньо узгоджується з викладачем – керівником студента на час проектування (далі керівник проекту або просто керівник).

Тема ДП може бути рекомендована кафедрою за матеріалами  виробничих та переддипломної практик, а також за матеріалами науково–дослідної роботи студента. ДП може розроблятися на замовлення підприємства, з яким у студента укладено договір на навчання.

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

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

Керівник здійснює наступні функції:

  •  узгодження теми ДП і видача студентові завдання на дипломне проектування;
  •  надання допомоги студентові щодо конкретизації змісту ДП і розробки календарного плану його виконання;
  •  консультації та науково–методичне керівництво роботою дипломника в процесі проектування;
  •  систематичний контроль за ходом виконання ДП;
  •  надання допомоги студентові у зборі основного та додаткового матеріалу для проектування;
  •  перевірка закінченого ДП та підготовка відгуку;
  •  підготовка студента до захисту ДП перед ДЕК.

На керівництво одним ДП викладачу виділяється близько 20 учбових годин. Графік щонедільних індивідуальних консультацій дипломник узгоджує з керівником на початку дипломування.

Кожному дипломнику кафедрою призначаються консультанти з розділів ДП. Вони допомагають студентові вирішити питання, пов'язані з вибором методів рішення завдань, визначити вимоги й вибрати засоби для реалізації завдання, зробити необхідні розрахунки. На консультації одного дипломника викладачу рішенням кафедри виділяється від 0,5 до 1 учбової години. Графік проведення консультацій складається та доводиться до відома студентів на початку дипломування.

 Керівник і консультанти покликані надавати науково–методичну допомогу студентові в його самостійній роботі при вирішенні наукових і практичних питань, в аналізі застосовуваних методів проектування і використання тих або інших технічних засобів для збору, реєстрації і обробки інформації та в інших питаннях. Вони сприяють творчій роботі, пов'язаній з пошуком нових, більш прогресивних проектних рішень з питань проектування АС. Однак відповідальність за прийняті в ДП остаточні рішення, правильність технологічних розробок і розрахунків покладається на автора проекту – студента – дипломника.

Для відміток про виконання календарного плану дипломник оформлює робочий зошит. На першій сторінці зошиту вказується тема ДП за приказом, номер та дата затвердження теми, дата здачі студентом закінченого ДП на кафедру та дата захисту. На другій сторінці наводиться скорочений календарний план виконання ДП з зазначенням назв етапів, термінів їх виконання (додаток В), а також вказуються прізвища консультантів з розділів та час проведення консультацій. Далі в зошиті наводиться розгорнутий календарний план за розділами, підрозділами та пунктами у вигляді табл. 1.1. Цю таблицю рекомендується виконувати в “альбомній ” орієнтації на двох сторінках зошита. При цьому стовпці 1-4 розміщують на лівій сторінці зошиту, а стовпці 5 та 6 –  на правій сторонці. Кожен розділ треба починати з нової сторінки.

Таблиця 1.1 Календарний план виконання ДП

№ пп

Найменування розділу, під-розділу, пункту або підпункту

Відмітки

керівника

Відмітки

консультанта

Узгодже-но

Вико-

нано

Узгоджено

Виконано

1

2

3

4

5

6

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

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

У робочому зошиті дипломник, керівник та консультанти роблять необхідні відмітки про хід виконання ДП, а при необхідності записують зауваження та уточнення.

Дипломник всі розділи ДП узгоджує  спочатку з керівником, а потім – з консультантом. Як правило, дипломник зустрічається з консультантом не менше 3-х разів:

  •  узгодження формулювання вимог до компонентів КП та індивідуального переліку варіантів рішень;
  •  представлення результатів роботи у вигляді частини пояснювальної записки (ПЗ), графічного матеріалу та списку використаних джерел;
  •  перевірка та підпис повністю готового ДП.

Після затвердження на кафедрі та допуску до захисту ДП направляється на рецензію. Резензування є заключним етапом дипломного проектування, на якому оцінюється професійна підготовленість студента до самостійної роботи у якості кваліфікованого спеціаліста, актуальність теми, повнота й науково–технічний рівень виконаної студентом розробки. Дипломник повинен уважно вивчити всі зауваження рецензента, оцінити їх важливість і підготувати аргументовані відповіді на захисті перед ДЕК.

Для документального підтвердження реальності виконаного ДП студент повинен представити до ДЕК довідку про можливість використання результатів або окремих проектних рішень на підприємстві.

2 ВИМОГИ ДО СТРУКТУРИ ДИПЛОМНОГО ПРОЕКТУ

2.1 Структура дипломного проекту

Дипломний проект складається із двох частин: ПЗ і графічних матеріалів.

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

Структурно ПЗ розділяється на три основні частини:

– вступна частина;

– основна частина;

– додатки.

Вступна частина містить наступні структурні елементи:

  •  обкладинка ДП;
  •  титульний лист;
  •  завдання й календарний план;
  •  лист зауважень;
  •  відомість обсягу ДП;
  •  реферат;
  •  зміст
  •  перелік умовних позначок і скорочень.

Основна частина повинна містити:

 – вступ;

– суть роботи (розділи основної частини ДП);

– висновок;

– перелік посилань.

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

Додатки оформлюють згідно зі стандартами [7,8]. Більш докладні вимоги до оформлення додатків у ПЗ викладені в підрозділі 4.7.

2.2 Вимоги до структурних елементів вступної частини

Обкладинка (сторінка 1 обкладинки) повинна дати користувачеві перше уявлення про проект і тому повинна бути чіткою, зрозумілою та інформативною. На зовнішній стороні першої сторінки обкладинки повинні бути наведені відомості про ДП:

– ідентифікатори;

– повне найменування;

– відомості про автора;

– рік виконання. 

Зразок оформлення першої сторінки обкладинки наведено у додатку А.

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

  •   віза завідувача кафедри про допуск до захисту ДП;
  •   найменування теми ДП;
  •   найменування спеціальної частини, якщо вона передбачена у ДП;
  •   підпис виконавця–студента;
  •   підпис керівника;
  •   підпису консультантів окремих розділів ДП;
  •   підпис нормоконтролера;
  •   дати.

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

Після завдання наводиться календарний план виконання ДП, який узгоджується з керівником.

Пункт 6 завдання та календарний план заповнюються одночасно з робочим зошитом дипломника.

 Лист зауважень – це чистий лист паперу формату А4 із заголовком “ЛИСТ ЗАУВАЖЕНЬ”. На цій сторінці при необхідності можуть записати свої зауваження керівник ДП та консультанти.

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

 Реферат призначено для ознайомлення з проектом. Він має бути коротким, інформативним і містити відомості, що дозволяють представити сутність ДП. Реферат повинен містити:

  •  бібліографічний опис ДП;
  •   текст реферату;
  •   перелік ключових слів.

Бібліографічний опис містить відомості про обсяг ПЗ, кількість ілюстрацій, таблиць, додатків, а  також кількість джерел у переліку посилань. Цей опис виконується відповідно до вимог діючих стандартів по бібліотечній і видавничій справі та має такий вигляд:

Дипломний проект: ___ с., __ рис., __ табл., __ додатків, __ джерел.

При цьому відомості приводяться з врахуванням всіх додатків.

Текст реферату має відображати інформацію, представлену в ПЗ та, як правило, у певній послідовності:

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

Частини реферату, відомості про які відсутні, не наводять. Обсяг реферату не більше 500 слів. Реферат  розташовується на одній сторінці формату А4.

Ключові слова, істотні для розкриття суті ДП, розміщують після тексту реферату. Перелік ключових слів містить від 5 до 15 слів (словосполучень), надрукованих прописними літерами в називному відмінку в рядки через коми.

Лист реферату виконується з основним написом (див. п.  3.8).

 Зміст розташовують після реферату, починаючи з нової сторінки. Зміст включає:

  •  перелік умовних позначок і скорочень;
  •  вступ;
  •  послідовно перераховані назви всіх розділів, підрозділів, пунктів і підпунктів (якщо вони є і мають заголовки);
  •   висновок;
  •   перелік посилань;
  •   послідовно перераховані додатки з заголовками.

У змісті вказуються номера сторінок, на яких розташовано початок відповідного матеріалу.

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

2.3 Вимоги до структурних елементів основної частини

 У вступі ДП  коротко викладають:

  •   оцінку сучасного стану задач (проблем),  що розв'язуються у проекті;
  •   мета роботи;
  •   актуальність даної роботи й підстава для її проведення;
  •   область застосування;

 Вступ розташовують на окремій сторінці.

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

Відповідальність за вірогідність відомостей, що наводяться в ПЗ, несе виконавець–студент.

 Висновок міститься після викладу суті роботи. Висновок для ДП є оцінкою основних результатів, отриманих студентом–дипломником у процесі виконання ДП в цілому. У висновку рекомендується перспективи розвитку підсистеми. Текст висновку може розділятися на пункти.

У переліку посилань наводиться перелік джерел, на які автор посилається в ПЗ. Перелік розташовується наприкінці тексту ПЗ, починаючи з нової сторінки.

Графічні матеріали – це окремо винесені на прозорі плівки для проекторів формату А4 або на листи формату А1 рисунки та текст із ПЗ, що містять структури, схеми, формули, таблиці та інший ілюстраційний матеріал, необхідний для доповіді під час захисту ДП.

2.4 Рекомендований зміст дипломного проекту

 

Нижче наведено рекомендований зміст ПЗ з зазначенням розділів та підрозділів.

ВСТУП

1 ТЕХНІЧНЕ ЗАВДАННЯ НА СТВОРЕННЯ ПІДСИСТЕМИ <назва>

1.1 Призначення і мета створення підсистеми

1.2 Характеристика об'єкта комп'ютеризації

1.3 Вимоги до підсистеми в цілому

1.4 Вимоги до функцій (або завдань), що виконуються підсистемою

1.5 Вимоги до видів забезпечення

2 ФУНКЦІОНАЛЬНА СТРУКТУРА ПІДСИСТЕМИ

2.1 Опис процесу виконання задачі (або функції) "..."

2.2 Опис процесу виконання задачі (або функції) "..."

...

2.(4) Функціонально–структурна схема підсистеми

3 ІНФОРМАЦІЙНЕ ЗАБЕЗПЕЧЕННЯ ПІДСИСТЕМИ

3.1 Вибір засобу управління даними

3.2 Розробка моделей даних

3.3 Реалізація бази даних

3.4 Організація збору та обробки інформації

4 МАТЕМАТИЧНЕ ЗАБЕЗПЕЧЕННЯ ПІДСИСТЕМИ

4.1 Опис алгоритму виконання задачі (або функції)  "..."

4.2 Опис алгоритму виконання задачі (або функції)  "..."

5 ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ПІДСИСТЕМИ

5.1 Структура і функції частин програмного забезпечення підсистеми

5.2 Вибір компонентів програмного забезпечення

5.3 Розробка спеціального програмного забезпечення підсистеми

5.3.1 Структура спеціального програмного забезпечення

5.3.2 Опис програмного модуля "..."

5.3.3 Опис програмного модуля "..."

6 ТЕХНІЧНЕ ЗАБЕЗПЕЧЕННЯ ПІДСИСТЕМИ

6.1 Вибір конфігурації й параметрів сервера

6.2 Вибір конфігурації й параметрів робочих станцій

6.3 Вибір периферійних пристроїв

7 ОРГАНІЗАЦІЯ КОМП'ЮТЕРНОЇ МЕРЕЖІ

7.1 Вибір і обґрунтування технології передачі даних

7.2 Вибір мережного устаткування

7.3 Вибір засобів забезпечення інформаційної безпеки

8 ТЕСТУВАННЯ ПІДСИСТЕМИ

8.1 Умови та порядок тестування

8.2 Вхідні дані для контрольного приклада

8.3 Результати тестування і їхній аналіз

9 РОЗРАХУНОК ЕКОНОМІЧНОЇ ЕФЕКТИВНОСТІ ПІДСИСТЕМИ

ВИСНОВОК

ПЕРЕЛІК ПОСИЛАНЬ

Додаток А <Назва першого додатку>

Додаток Б <Назва другого додатку>

Наведений вище рекомендований зміст ПЗ дипломного проекту – це тільки склад обов'язкових розділів ДП, за якими студент виконує проектування компонентів ІУС.

У рекомендованому змісті наведені тільки основні розділи та підрозділи. Пункти не вказані та будуть описані нижче. Використання підпунктів у ПЗ не бажано. При необхідності, за узгодженням з керівником ДП  і консультантами, склад окремих розділів та їх назви можуть бути скореговані .

Розділ 9, присвячений оцінці економічної ефективності КП, виконується відповідно до вимог, затверджених кафедрою економіки.

3 РЕКОМЕНДАЦІЇ З ВИКОНАННЯ ОКРЕМИХ РОЗДІЛІВ

ДИПЛОМНОГО ПРОЕКТУ

3.1 Рекомендації з розробки технічного завдання

Розділ "Технічне завдання на створення підсистеми" містить характеристику об'єкта комп'ютеризації, основні вимоги до проектованої підсистеми і є визначальним для наступних розділів ДП. Технічне завдання (ТЗ) узгоджується, в першу чергу, з керівником, після чого воно представляється консультантам з відповідних розділів. Без погодженого ТЗ консультації з інших розділів ДП не проводяться. При формулюванні різних вимог до підсистеми необхідно враховувати, що буде потрібно забезпечити виконання цих вимог при проектуванні відповідних частин. Зміст окремих підрозділів ТЗ наведено нижче.

У підрозділі “Призначення й мети створення підсистеми” описується призначення КП та мети її створення.

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

До складу підрозділу “Характеристика об'єкта комп'ютеризації можуть входити наступні пункти:

1.2.1 Опис структури й процесу функціонування об'єкта

1.2.2 Існуюча інформаційна система і її недоліки

1.2.3 Аналітичний огляд розроблених АС та КП

1.2.4 Обґрунтування необхідності вдосконалення інформаційної

 системи.

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

У пункті 1.2.2 описуються основні операції, що виконуються при зборі та обробці інформації, пов'язані з ними документи, інші види даних, що використовуються. Ці описи можна ілюструвати схемою документообігу та інших рисунків. Форми документів можна привести в додатку.

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

У пункті 1.2.3 дається коротка характеристика не менш, ніж 2 розроблених автоматизованих систем (підсистем), що можуть бути застосовані до даного об'єкта комп'ютеризації. При цьому по кожній системі вказуються основні параметри й можливості, відзначаються переваги та недоліки. Наприкінці робиться висновок про можливість або неможливість використання цих систем.

У пункті 1.2.4 дається обґрунтування необхідності вдосконалювання інформаційної системи. У цьому підпункті, з урахуванням специфіки об'єкта комп'ютеризації, недоліків існуючої інформаційної системи, результатів аналізу розроблених автоматизованих систем викладаються причини, внаслідок яких створення даної КП є необхідним. Потім указуються ті очікувані позитивні результати, які будуть отримані в процесі роботи цієї КП.

До складу підрозділу “Вимоги до підсистеми в цілому” можуть входити наступні пункти:

1.3.1 Вимоги до структури й функціонування підсистеми

1.3.2 Інші вимоги

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

У пункті 1.3.2 указуються додаткові вимоги до підсистеми:

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

Склад вимог у цьому пункті визначається за узгодженням з керівником ДП.

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

1.4.1 Вимоги до задачі (або функції) ...

1.4.2 Вимоги до задачі (або функції) ...

1.4.3 Вимоги до задачі (або функції) ...

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

Кількість пунктів в підрозділі 1.4 визначається відповідно до КП, але не може бути меншим ніж 3.  

По кожній задачі (функції) указуються наступні вимоги до:

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

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

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

В описі по кожній структурній одиниці інформації варто вказувати:

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

Основними вихідними документами обираються такі, форми яких встановлюються Держкомстатом, міністерством або іншим органом влади. Заповнені зразки вихідних документів приводяться в додатку.

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

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

В якості вхідних документів головним чином обираються такі, що вже використовуються на об’єкті. У виключних випадках в ДП розробляються нові документи. Заповнені зразки вхідних документів приводяться в додатку.

Для задач АС управління технологічними процесами (АСУТП) вказують наступні переліки:

  •  перелік вихідних сигналів;
  •  перелік вхідних даних.

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

Для вхідних сигналів в залежності від типу вказують:

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

У підрозділі “Вимоги до видів забезпечення” формуються певні вимоги, які необхідно буде реалізувати в ДП. До складу підрозділу 1.5 мають входити наступні пункти:

1.5.1 Вимоги до математичного забезпечення

1.5.2 Вимоги до інформаційного забезпечення

1.5.3 Вимоги до програмного забезпечення

1.5.4 Вимоги до технічного забезпечення

1.5.5 Вимоги до комп'ютерної мережі

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

Вимоги до інформаційного забезпечення (ІЗ) можуть включати наступні пункти:

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

У вимогах до програмного забезпечення (ПрЗ) вказуються:

– вимоги до структури ПрЗ підсистеми;

– вимоги до операційного середовища;

– вимоги до інструментальних засобів розробки ПрЗ;

– вимоги до використання готових програмних пакетів (комплексів);

–вимоги до склад і функцій спеціального (прикладного) ПрЗ, що підлягає розробці;

– вимоги до допоміжних програмних засобів (сервісні програми й утиліти).

У вимогах до технічного забезпечення (ТехЗ) підсистеми  вказуються вимоги до функціональних, конструктивних й експлуатаційних характеристик засобів ТехЗ підсистеми (без мережного устаткування), а саме вимоги щодо вибору двох конфігурацій комп'ютерів: комп'ютера для сервера й комп'ютера для робочих станцій.

При формулюванні вимог до ТехЗ необхідно враховувати, що ці вимоги обумовлені специфікою завдань, що розв'язуються у підсистемі, та вимогами до інших частин підсистеми, що сформульовані перед цим.

При описі вимог до ТехЗ необхідно вказувати не конкретні значення характеристик апаратних компонентів або конкретні типи, а лише розумні обмеження на ці характеристики. Наприклад, не слід писати  …основна пам'ять повинна підтримувати частоту шини N МГц, … повинна бути побудована на модулях типу …. Вірнішою тут могла бути фраза …частота, підтримувана основною пам'яттю комп'ютера, повинна бути не нижче N Мгц... з наступним обґрунтуванням.

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

Ясно, наприклад, що обмеження на характеристики компонентів сервера й робочої станції можуть доволі сильно розрізнятися й бути зовсім різного порядку. Наприклад, параметри обсягу пам'яті, дисків, швидкодії процесорів, можливості системної плати. Можливо, що з урахуванням умов розробки або розвитку підсистеми можуть знадобитися й обмеження вартісного характеру або обмеження на енергоспоживання. Але в кожному разі, говорячи про будь яке обмеження  не менше, не більше, не нижче, після їх короткого переліку,  не далі ніж у наступному абзаці необхідно зазначити,  з чого кожне з них випливає. Кожне таке зазначення  має бути коротким, у межах 5–10 слів.

У вимогах до комп'ютерної мережі (КМ) вказують:

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

Вимоги до компонентів підсистеми узгоджується спочатку з керівником, а потім з консультантом з відповідного розділу.

3.2 Рекомендації з розробки функціональної структури

Дипломник складає докладний опис процесів виконання кожної задачі або функції КП в окремих підрозділах 2.1,2.2,2.3 та ін., відповідно до вимог, які були сформовані у п.1.4.1 – 1.4.3. При необхідності дається опис вхідних даних, якщо вони змінюються, опис автоматизованих функцій, що направлені на досягнення цілей КП. Також даються необхідні пояснення до розділення функцій, що автоматизуються, на дії (операції), які виконуються технічними засобами або людиною. Всі дії КП спрямовані на комп'ютерну обробку вхідної інформації, що може бути надходити на паперових носіях (документах), по електронній пошті або усних повідомлень. Для демонстрації дій (функцій), які виконує КП, будується функціонально–структурна схема.

Дипломник за допомогою прикладного пакета будує модель бізнес–процесів. Модель повинна представляти собою сукупність ієрархічно впорядкованих і взаємозалежних діаграм. Кожна діаграма є одиницею опису системи й повинна розташовуватися на окремому листі.

Модель повинна містити наступні види діаграм:

– контекстна діаграма (у кожній моделі процесів може бути тільки одна контекстна діаграма);

– діаграма декомпозиції.

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

Функції, процеси, роботи або завдання, які виконує КП, повинні мати результати, що добре розпізнаються. Роботи повинні бути названі й визначені у формі віддієслівного іменника. Найменування роботи вказується в прямокутнику діаграми. Кожна робота на діаграмі може бути декомпозована на 3–6 робіт  нижнього рівня. За допомогою відповідних стрілок та кодів  необхідно виконати зв'язок робіт між собою й зовнішнім середовищем.

Функціонально–структурна схема розміщується по тексту ПЗ або у додатках.

3.3 Рекомендації з розробки інформаційного забезпечення

У підрозділі “Вибір засобу управління даними“ дипломник визначає спосіб представлення даних, що будуть зберігатися у підсистемі. Як правило, робиться порівняння різних даталогічних моделей та вибір реляційної моделі даних. Далі проводиться порівняння 2–х сучасних систем управління базами даних (СУБД) серверного типу приблизно однакової потужності. Проводиться обґрунтування вибору однієї з них як засобу управління даними у КП. Рекомендується звести кількісні показники СУБД, що порівнюються,  в таблицю.

При необхідності провадиться вибір окремої СУБД для клієнтської частини. Тоді підрозділ рекомендується назвати “Вибір засобів управління даними”.

У підрозділі “Розробка моделей даних” студент розробляє логічну та фізичну моделі предметної області.

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

Для прискорення процесу краще створити початковий набір таблиць за принципом “Один факт зберігається в одному місці”. Для цього треба виділити основні об’єкти предметної області та розмістити їх властивості як атрибути по різних таблицях.  Можна кожному вхідному первинному обліковому документу поставити у відповідність одну таблицю. Але треба пам’ятати, що документ зі звичайним “паперовими” таблицями розбивається за принципом: одна “паперова” таблиця – одна сутність. Наприклад, накладна на товар – це дві сутності (“Накладна” та “Матеріали за накладною”).

Кількість сутностей у моделі залежить від предметної області,  але має бути не менше 10.

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

Студент може зазначити, що  розробка та впровадження автоматизованого ведення загальнодержавних класифікаторів ведеться на державному рівні, тому ці питання в ДП не розглядаються. У списку джерел наводиться перелік основних чинних класифікаторів.

У підрозділі наводиться опис структури та розрядність кодів. Рекомендується навести рисунки для пояснення структур або схем кодових позначень,  а у додатку навести витяги з потрібних класифікаторів на 1 сторінку. Студент може виділити підрозділ “Опис систем класифікації та кодування”

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

Рекомендується імена та призначення сутностей навести у вигляді табл. 3.1. Сутності у табл. 3.1 можна поділити на оперативні та довідкові.

Таблиця  3.1   Сутності моделі “_____________”

Сутність

Опис

1

Співробітники

Інформація про співробітників підприємства

2

……...

Для кожної сутності треба описати її атрибути. Це можна зробити  у вигляді табл. 3.2.

Таблиця 3.2    Атрибути сутностей моделі

Сутність

Атрибути

1

Співробітники

Ідентифікаційний номер, прізвище, ім’я, по–батькові,....

2

……...

По тексту ПЗ рекомендується навести описання атрибутів двох – трьох основних зв’язаних оперативних сутностей, інші описання треба винести до додатку.

При визначенні ключів треба використовувати діючі системи класифікації та кодування або вводити штучні атрибути типу лічильника.

Таблиці 3.1–3.2 можна доповнити звичайним текстом, описуючи кожну сутність окремо, або використати мову інфологічного моделювання.

Логічна модель БД будується за допомогою того програмного CASE–пакету візуального моделювання, який погоджено з керівником та консультантом. Дипломник повинен на 1–2 сторінках ПЗ обґрунтувати вибір засобу розробки моделі даних з врахуванням СУБД.

При розробці моделі визначаються сутності, їх ключі та атрибути, а також зв’язки між сутностями. На цьому етапі також необхідно виявити поля, що обчислюються.  Далі необхідно  виконати процедуру нормалізації БД методом нормальних форм та вилучити в таблицях:

  •  часткові залежності неключових полів від ключа;
  •  транзитивні залежності неключових полів від ключа;
  •  багатозначні залежності.

Для полів, що обчислюються, рекомендується вказати, що розрахункові формули будуть наведені нижче у інших розділах.

Треба пам’ятати, що мета логічного моделювання – це таблиці у нормальних формах вищого порядку. Разом з тим, використання БКНФ може привести до значного збільшення кількості таблиць у моделі та появи додаткових зв’язків типу 1:1. Тому студент може обґрунтувати та провести незначну денормалізацію моделі.

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

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

Опис характеру в'язків у БД та умови цілісності даних можна навести у вигляді табл. 3.3.

Таблиця 3.3  Зв'язки між сутностями

Батьківська сутність

Дочірня сутність

Тип зв'язку

Назва

Атрибут

Назва

Атрибут

Логічна модель наводиться у вигляді рисунку.

Для переходу до фізичної моделі сутності замінюються реляційними таблицями, атрибути – полями. Імена полів, їх тип та розмір визначаються  згідно з інформацією, що необхідно зберігати в БД, з урахуванням правил і можливостей СУБД. Рекомендується визначати властивості таблиць та полів так, щоб забезпечити максимальний контроль даних та довести таблиці до вищої домено–ключової нормальної форми.

Для обміну інформацією з користувачами в інших організаціях в ДП  треба передбачити використання підсумкових dbf–файлів.  Студент дає короткий опис цих файлів та файлів–класифікаторів  як таблиць формату dbf.

Опис фізичної моделі рекомендується виконати у вигляді табл. 3.4.

Таблиця 3.4     Структура таблиці _________

 №

Поле

Тип

Розмір

Довжина, б

Властивості

Підпис

 

Всього

По тексту ПЗ рекомендується навести описання двох–трьох основних зв’язаних таблиць, описання інших треба винести до додатку.

В ПЗ наводиться рисунок фізичної моделі, яка використовується для формування програми створення машинної БД.

У підрозділі “Реалізація бази даних” дипломник наводить опис реалізації БД у середовищі вибраної СУБД.

Спочатку дається короткий опис програми створення БД. Фрагмент  програми  на 2– 3 сторінки необхідно навести у додатку до ПЗ.

Далі студент описує реалізацію БД у середовищі заданої СУБД. При цьому описуються остаточні властивості полів та засоби їх визначення. Дані вносяться до табл.2.4. При цьому окремо позначаються властивості, що визначені на стадії фізичної моделі, і властивості, що визначені на стадії реалізації БД. Для більшої наочності табл.2.4 треба наводити у “альбомній” орієнтації.

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

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

Далі дається опис характеру зв'язків у БД та умови цілісності даних, які можна навести у вигляді табл. 3.5

Таблиця 3.5  Зв'язки між таблицями

Батьківська таблиця

Дочірня таблиця

Зв'язок

Тип

Відновлення

Вилучення

Назва

Індекс

Назва

Індекс

Варто навести короткий опис методів підтримки цілісності даних у БД. Можна до додатку віднести фрагменти вбудованих процедур, тригерів або опис системних таблиць.

Для наочності обов'язково наводиться екранна форма конструктору БД, яка реалізована в ДП. На цьому рисунку додатково вказуються типи та розміри полів.

При можливості треба розробити поля підстановок даних в таблиці з батьківських джерел. При необхідності треба розробити відповідні запити та навести опис властивостей для підстановок полів.

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

Таблиця 3.6    Перелік об’єктів БД

№ пп

Ім'я об’єкту

Призначення об’єкту

Запити, представлення

1

зСпівробітники

формування ПІБ співробітників

Вбудовані процедури

1

ri_Insert1

підтримка цілісності даних при додаванні нового запису

Студент повинен у ПЗ навести опис найбільш важливих об’єктів і навести SQL–команду або текст процедур,  а також результати виконання.

Якщо для одержання якого–небудь запиту або представлення використовувалися інші об’єкти, то варто в додатку навести весь каскад  SQL–інструкцій. Рекомендується зробити рисунок взаємодії об’єктів БД при формуванні одного з запитів.

Запити, що використовуються як джерела для форм ведення даних або для формування, рекомендується описати в розділі з рішеннями з ПрЗ. Про це студент робить відповідне посилання.

В цьому підрозділі необхідно провести розрахунок об'єму необхідної дискової пам'яті. Цей розрахунок проводиться на мінімальний термін використання БД (п’ять років). Розрахунок можна звести у вигляді табл. 3.7.

Таблиця 3.7   Розрахунок об'єму БД

Назва

таблиці

Об'єм заголовку

Об'єм 1–го запису

Кількість записів

Об'єм записів

Загальний об'єм

                                                     Усього

При розрахунках треба оцінити можливий обсяг всіх інших файлів БД (системних файлів, індексів та ін.).

Навіть якщо в ДП не вимагається розробляти та описувати БД для архіву інформації, її можливий обсяг треба врахувати при оцінці загального обсягу машинних носіїв.

У підрозділі  “Організація збору та обробки інформації” наводиться схема збору, обробки й передачі інформації та дається її опис. Схему рекомендується наводити зліва–направо (від прийому та перевірки вхідних документів або файлів до формування та передачі вихідних документів або файлів за призначенням). Опис схеми має бути докладним. Автор повинен описати організацію ведення БД та  навести засоби її захисту від руйнування і несанкціонованого доступу, а також регламент процедур обслуговування (перевірка, пакування, копіювання, створення архівів). Рекомендується також сформулювати послідовність процедур з маршруту обробки вхідної інформації  до передачі на автоматизовану обробку та маршрут руху вихідних документів.

Якщо в ДП використовується існуюча на об’єкті оперативна БД, а однією з задач проекту було обрано задачу аналізу даних та прийняття рішень,  то в розділі 3 дипломник, за узгодженням з керівником і консультантом, може розробити  компоненти сховищ даних. Підрозділи в цьому випадку можуть мати такий перелік:

3.1 Опис бази даних

3.2 Вибір засобів створення сховищ даних

3.3 Вибір моделі сховища даних

3.4 Розробка сховища даних

3.5 Організація збору та обробки інформації

В кінці 3-ого розділу треба навести конкретні засоби виконання вимог до ІЗ, що були сформовані у підрозділі 1.5. Якщо виконання деяких вимог не реалізовано на рівні БД, то треба сформувати додаткові вимоги до ПрЗ. Також можуть уточнюватися вимоги до вхідної та вихідної інформації, які було наведено раніше (підрозділи 1.4, 2.1 – 2.3), і вимоги до ТехЗ з точки зору обраних СУБД та БД.

3.4 Рекомендації з розробки математичного забезпечення

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

Опис кожного алгоритму рішення задачі (виконання функції) приводиться в наступній послідовності:

  •  призначення і характеристика;
  •  інформація, що використовується;
  •  результати рішення;
  •  математичний опис;
  •  алгоритм рішення.

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

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

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

Математичний опис виконується за узгодженням з консультантом. Приводять математичну модель або економіко–математичний опис процесу (об'єкта); методи обчислень. Цей пункт є обов'язковим в описі алгоритмів задач, пов'язаних з оптимізацією, моделюванням, аналізом і прогнозуванням. Його склад узгоджується з консультантом. Для завдань облікового характеру необхідність цього пункту визначається керівником.

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

Алгоритм в основному представляються змішаним способом, а саме графічним у вигляді блок–схеми з поясненням у вигляді тексту. Спосіб подання алгоритму вибирається студентом за узгодженням з керівником.

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

 

3.5 Рекомендації з розробки програмного забезпечення

При описі структури і функцій частин програмного забезпечення підсистеми приводиться укрупнений опис складових частин ПрЗ, необхідного для розробки й експлуатації підсистеми, включаючи: загальносистемне ПрЗ, інструментальні засоби, сервісні програми й утиліти, спеціальне ПрЗ тощо. По кожній із перелічених частин ПрЗ коротко описуються її склад, призначення й основні виконувані функції. Структура і склад спеціального ПрЗ представляються в укрупненому вигляді: кінцевий програмний продукт і основні функціональні модулі, які входять до нього (без деталізації до рівня конкретних форм і звітів). Загальна структура ПрЗ підсистеми представляється у вигляді рисунку, що може також бути винесено на демонстраційний лист. Обсяг цього пункту 2–3 сторінки.

Підрозділ 5.2 “Вибір компонентів програмного забезпечення” може включати такі пункти:

5.2.1 Операційні системи для сервера і робочих станцій

5.2.2 Засоби розробки спеціального програмного забезпечення

5.2.3 Сервісні програми та утиліти

У п. 5.2.1 проводиться аналіз й обґрунтований вибір операційних систем (ОС) для сервера КМ і для робочих станцій (в окремих підпунктах). Для аналізу вибирається не менш 2–х сучасних претендентів по кожному виду ОС. По кожній ОС, що розглядається, приводяться основні параметри й відрізні риси без детального опису структури й принципів роботи. У результаті аналізу робиться висновок, на підставі чого вибирається зазначений тип ОС. Обсяг цього пункту 3–4 сторінки.

У п. 5.2.2 проводиться аналіз і обґрунтований вибір засобів або засобу для розробки спеціального ПрЗ. Для аналізу вибирається не менш 2–х сучасних систем (мов) програмування або СУБД, які придатні для розробки програм необхідного типу. Для кожного засобу вказуються основні можливості й характерні риси без докладного опису мови програмування, інтегрованого середовища тощо. У результаті аналізу робиться висновок, на підставі чого вибирається засіб розробки спеціального ПрЗ. Обсяг цього пункту 1,5–2 сторінки.

У п. 5.2.3 проводиться аналіз і обґрунтований вибір сервісних програм і утиліт, необхідних для забезпечення функціонування підсистеми: архіваторів, антивірусів, офісних програм (редакторів, електронних таблиць тощо), графічних пакетів та інших допоміжних програмних засобів. По кожному виду програмних засобів аналізується кілька можливих сучасних претендентів, потім указується, який з них обраний і чому. Обсяг цього пункту 1,5–2 сторінки.

Підрозділ 5.3 "Розробка спеціального програмного забезпечення" може включати такі пункти:

5.3.1 Структура спеціального програмного забезпечення

5.3.2 Опис програмного модуля ...

5.3.3 Опис програмного модуля ...

У п. 5.3.1 узагальнено описується склад і структура розробленого спеціального ПрЗ, наводиться перелік розроблених програмних продуктів (якщо їх небагато), вказується їх призначення. Для кожного програмного продукту приводиться рисунок у вигляді ієрархічної структури, що відображає склад різних об'єктів (форм, звітів, програмних файлів тощо) для основних функціональних модулів КП. Приводиться також головна екранна форма програмного додатку і дається її короткий опис. Обсяг цього пункту 2–3 сторінки разом з рисунками.

У пунктах 5.3.2, 5.3.3 і далі приводяться описи основних функціональних модулів програми (наприклад, модуль даних, ведення довідників, облік ..., формування звітів, тощо). Кількість подібних пунктів може дорівнювати кількості функцій, що були описані у розділі 2.

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

Обсяг кожного з таких пунктів залежить від складності відповідного програмного модуля.

У додатки можуть бути поміщені:

  •  листинги основних програмних модулів (максимальний обсяг 10 сторінок за узгодженням з консультантом);
    •  коротке керівництво для користувача.

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

Рекомендується скласти та коротко описати схему взаємодії БД і спеціального ПрЗ. Схему рекомендується будувати ієрархічно знизу – догори, від таблиць до головної форми меню.

3.6 Рекомендації з розробки технічного забезпечення

У розділі 6 “Технічне забезпечення” розглядається весь комплекс питань щодо технічних засобів КП, за винятком апаратних компонентів, що безпосередньо використовуються для організації КМ. Компоненти КМ, як правило, розглядаються в окремому розділі 7.

Оскільки підсистеми, що розроблюються в дипломних проектах, мають бути реалізовані на основі КМ, то  у розділі 6 слід відображати рішення щодо вибору двох конфігурацій персональних комп'ютерів (ПК) мережі: комп'ютера для сервера й комп'ютера для робочих станцій.

Для кожної із цих двох конфігурацій  у підрозділах 6.1 та 6.2 відповідно, необхідно навести вибір характеристик і типів пристроїв, що входять до стандартного набору для ПК:

– системної плати;

– процесора;

– основної пам'яті;

– відеосистеми, що включає монітор і відеоадаптер;

– накопичувачів на магнітних дисках і на компакт–дисках.

Крім того, у проектованих  підсистемах  можуть знадобитися різні периферійні пристрої (ПП), що не входять у стандартний для ПК набір. Сюди можна віднести такі пристрої як принтери, сканери, джерела безперебійного живлення, у деяких випадках – планшетні графобудівники, можливо різні датчики, виконавчі механізми, тощо. Тому в ТЗ   на створення підсистеми слід зазначити також вимоги  до характеристик таких ПП, а в розділі 6 треба, поряд з підрозділами 6.1 і 6.2, у яких описується вибір комплектуючих для сервера і робочих станцій мережі, організувати додатково підрозділ 6.3, що описує проектні рішення з ПП.

Комп'ютерний ринок пропонує досить велику номенклатуру компонентів для ПК різних характеристик і конфігурацій. Тому важливою рисою дипломника  у цих умовах є його вміння орієнтуватися в цьому ринку, обґрунтовано вибирати на  ньому саме необхідне для його підсистеми за умовами та вимогами, висунутими у ТЗ. Слід зауважити, що треба враховувати не тільки поточний стан, а й можливий розвиток проекту. Не менш важливою рисою спеціаліста має бути його вміння аргументовано пояснювати свій вибір іншим, наприклад, замовникові або колегам. Ось ці вміння, на основі відповідних знань, дипломник і повинен продемонструвати в цьому розділі ДП.

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

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

У даному розділі не повинно бути повторень загальних фраз із довідкових джерел (літератури, інтернет–джерел та ін.). Огляди з комп'ютерної техніки із преси та книг потрібно використати  для формування власної аргументованої думки про переваги або недоліки тих або інших технічних засобів та їх порівняння, але не для тексту в ПЗ. Велике цитування не допускається. Використання матеріалів оглядів має бути  критичним і підпорядкованим ідеї та логіці дипломного проектування: не матеріал заради матеріалу, тобто не уривки оглядів, а тільки те, що ілюструє процес формування проектних рішень. За необхідністю можна навести, як тезу, невелику цитату, критично осмислюючи її стосовно до умов ТЗ проекту. Цитата має бути не більше 2–3 речень і може використовуватися лише у випадках, коли це допоможе краще довести основну думку на певному етапі проектування.

Оскільки ринок комп'ютерної техніки стрімко змінюється, для пошуку необхідної інформації треба використати джерела у межах останнього календарного року.

При виборі компонентів ТехЗ рекомендується дотримуватися наступного порядку:

  1.  Вибирається прайс–лист якої–небудь відомої фірми із продажу і обслуговування комп'ютерної техніки. Прайс має бути новим, не старішим 3 – 4 місяців давнини. Ксерокопію частини цього прайса рекомендується помістити в додатку.
  2.  З цього прайс–листа дипломник вибирає “кандидатури” компонентів за кожною позицією ( системна плата, процесор, основна та дискова пам'ять, відеосистема, принтер та інші ПП ) для сервера і позначає їх у прайсі та в додатку позначкою “С” ліворуч від відповідного рядка прайс–листа.
  3.  Потім у тому ж прайс–листі дипломник аналогічно позначає за кожною позицією позначкою “Р” ті компоненти, що передбачаються для робочої станції.
  4.  У ПЗ вибір кожного із згаданих компонентів обґрунтовується шляхом зіставлення й критичного порівняння факторів (характеристик), обраних дипломником та зазначених у відповідному рядку прайс–листа, з 2–3 альтернативними варіантами, наведеними в інших рядках прайс–листа. Перелік альтернативних рядків для порівняння узгоджується з консультантом.

Обсяг  розділу не повинен  перевищувати 15–20 сторінок.

3.7 Рекомендації з розробки комп’ютерної мережі

У підрозділі 7.1 “Вибір і обґрунтування технології передачі даних” на базі аналізу підприємства або організації, для якої проектується комп'ютерна мережа, необхідно:

  •  вибрати кількість робочих станцій в мережі, які потрібні для обслуговування всіх підрозділів (або одного з них, якщо мережа велика і складається з декількох сегментів) і вирішення сформульованих завдань;
  •  надати спрощений план розміщення приміщень усіх підрозділів і робочих станцій;
  •  вибрати й обґрунтувати технологію, що використана в проектованій КМ.

В підрозділі 7.2 “Вибір мережного устаткування” необхідно:

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

Якщо в ТЗ сформульовані вимоги до захисту інформації в мережі, то в підрозділі 7.3 “Вибір засобів забезпечення інформаційної безпеки” необхідно:

  •  спланувати заходи щодо захисту інформації в КМ, що проектується;
    •  описати організаційні заходи, які необхідні для нормальної роботи комп'ютерної мережі;
      •  навести конфігурацію програмних засобів захисту мережі (вибрані захищені протоколи, всі правила фільтрації трафіку на брандмауерах тощо).

3.8 Рекомендації з тестування підсистеми

У розділі "Тестування підсистеми" представляються і описуються матеріали, що підтверджують відповідність спроектованої підсистеми основним вимогам ТЗ, таким як виконання функцій (завдань) і вимогам до окремих видів забезпечення. Тестування проводиться на контрольному прикладі. Контрольний приклад має носити реальний характер, його обсяг має бути достатнім для перевірки працездатності компонентів підсистеми. Умови, обсяг і порядок тестування визначаються за узгодженням з керівником.

У підрозділі “Умови й порядок тестування” спочатку вказуються цілі і завдання, які мають бути досягнуті й вирішені в процесі тестування. Потім приводиться перелік об'єктів тестування (база даних, програмне забезпечення тощо). Після цього описуються умови тестування: для якого підприємства і підрозділу, які та за який період використані реальні дані. Описується загальний порядок тестування, тобто послідовність виконання операцій, що дозволяють перевірити працездатність і правильність функціонування підсистеми.

У підрозділі “Вхідні дані для контрольного приклада” дається докладний опис різних видів вхідних даних, використаних для тестування, перелік яких зазначено у попередньому пункті. Це можуть бути первинні документи, заповнені вручну або друкованим способом, а також різна нормативно–довідкова інформація: класифікатори, довідники тощо.

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

У підрозділі “Результати тестування та їх аналіз” приводиться опис основних результатів, одержаних у процесі тестування компонентів КП. Для інформаційного забезпечення таким результатом є вміст таблиць БД. Для ПрЗ результатами є заповнені екранні форми, сформовані звіти. Для ТехЗ результатами можуть бути швидкісні характеристики рішення контрольних прикладів. При тестуванні інших видів забезпечення вид та обсяги результатів визначаються за узгодженням з керівником.

При описі й аналізі отриманих результатів можна частину їх приводити у тексті ПЗ у вигляді надрукованого вмісту основних таблиць БД (по 0,5 стор.) і деяких екранних форм. Основну частину результатів необхідно помістити в додатку. Наприкінці цього пункту робиться загальний висновок щодо працездатності розробленої підсистеми й відповідності її вимогам ТЗ.

4 ВИМОГИ ДО ОФОРМЛЕННЯ ДИПЛОМНОГО ПРОЕКТУ

4.1 Загальні вимоги

 ПЗ оформляють на листах формату А4 (210х297 мм) відповідно до стандартів [7–9]. Досить докладно вимоги до оформлення наведено у наскрізній програмі практик [10]. Вважається, що студент повинен добре знати ці вимоги, бо він протягом навчання оформлював кілька курсових робіт або проектів, а також щонайменше тричі оформлював звіти з різних видів практики. Тому в даних методичних вказівках наведено  тільки деякі основні вимоги до оформлення ДП, в яких студент часто припускається помилок.

ПЗ друкують за допомогою комп'ютерної техніки на одній стороні листа білого паперу.

Об'єм ПЗ без додатків має становити 100 – 120 сторінок друкованого тексту. Для друку вибирається шрифт Times New Roman, розмір 14, інтервал 1,5. Додатки можуть становити 20 – 40 сторінок. Максимальний об'єм ПЗ – 150 сторінок. ПЗ виконується українською мовою.

Рекомендується дотримуватись наступних розмірів полів: ліве – 25 мм, верхнє та нижнє – 20 мм,  праве – 15 мм. Розміри вказано для “книжкової” орієнтації листа. Треба враховувати, що при “альбомній” орієнтації ці розміри відповідно будуть дорівнювати: верхнє – 25 мм, ліве та праве – 20 мм,  нижнє – 15 мм.

У ПЗ мають бути чіткі, не розпливчасті лінії, букви, цифри й інші знаки. За стандартом всі букви, цифри й знаки мають бути однаково чорними впродовж усієї ПЗ. Але останнім часом допускається використовувати можливості сучасних комп’ютерних редакторів та виділяти заголовки жирністю, а тексти програм, назви рисунків та таблиць – курсивом.  

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

Абзаци в тексті виділяють відступом. Абзацний відступ має бути однаковим впродовж усього тексту і дорівнювати п'яти знакам. Як правило, абзацний відступ дорівнює 1,25 см. Допускається відступ 1,5 см. Кожен пункт, підпункт і перелік мають абзацний відступ.

 Структурні елементи Реферат, Перелік умовних позначок і скорочень, Вступ, Висновок, Перелік посилань не нумерують, а їх найменування служать заголовками структурних елементів.

 Розділи, підрозділи, пункти, підпункти треба нумерувати арабськими цифрами. Розділи ПЗ повинні мати порядкову нумерацію в межах викладу суті. Підрозділи повинні мати порядкову нумерацію в межах кожного розділу. Номер підрозділу складається з номера розділу й порядкового номера підрозділу, розділених крапкою. Після номера підрозділу крапку не ставлять, наприклад 1.1 , 1.2 і т.д. Пункти повинні мати порядкову нумерацію в межах кожного підрозділу, наприклад, 1.1.1, 1.1.2 і т.д.

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

 Сторінки ПЗ належить нумерувати арабськими цифрами, дотримуючись наскрізної нумерації впродовж усього тексту. Номер сторінки проставляють у правому верхньому куті сторінки без крапки наприкінці.  Титульний лист, лист завдання включають у загальну нумерацію сторінок ПЗ. Номера сторінок на них не проставляють. Ілюстрації і таблиці, розташовані на окремих сторінках, включають у загальну нумерацію сторінок ПЗ.

Текст ПЗ повинен бути коротким, чітким і не допускати різних тлумачень. При викладі обов'язкових вимог мають застосовуватися слова: повинен, треба, необхідно, потрібно, щоб, дозволяється тільки, не допускається, забороняється, не треба. При викладі інших положень слід застосовувати слова: як правило, за необхідністю, може бути, можуть бути тощо.

4.2 Оформлення ілюстрацій

Кількість ілюстрацій повинна бути достатньою для пояснення тексту, що викладається.

 Ілюстрації (креслення, рисунки, графіки, схеми, діаграми, фотознімки) варто розташовувати в ПЗ безпосередньо після тексту, у якому вони згадуються вперше, або на наступній сторінці.

 Ілюстрації можуть мати назву, яку поміщають під ілюстрацією.

При необхідності під ілюстрацією поміщають підрисуночний текст для пояснення.

Ілюстрація позначається словом Рисунок, яке разом з номером та назвою ілюстрації поміщають після пояснюючих даних. Нумерують ілюстрації арабськими цифрами по порядку в межах розділу або  додатку. Номер ілюстрації складається з номера розділу й порядкового номера ілюстрації, розділених крапкою, наприклад: ”Рисунок 3.1 - Схема розміщення” - це перший рисунок третього розділу, ”Рисунок Б.2 - Схема документообігу” - це другий рисунок додатку Б.

На всі ілюстрації мають бути посилання в ПЗ. При посиланнях на ілюстрації слід писати  ...відповідно до рисунка 1.2 або ...відповідно до рис. 1.2.

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

Ілюстрації повинні відповідати вимогам діючих стандартів “Єдиної системи конструкторської документації” (ЄСКД) і “Єдиної системи програмної документації” (ЄСПД).  Схеми алгоритмів, програм, даних і систем виконуються відповідно до стандарту [8].  

 Допускається розміщувати в ПЗ ілюстрації, що виконані методом ксерокопії.

 Ксерокопії та фотознімки розміром менше формату А4 повинні бути наклеєні на листах білого паперу формату А4.

4.3 Оформлення таблиць

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

 При переносі частини таблиці на ту ж або інші сторінки назву поміщають тільки над першою частиною таблиці.

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

 Таблиці кожного додатка позначають окремою нумерацією арабськими цифрами з додаванням перед цифрою позначення додатка. Якщо в документі одна таблиця, вона повинна бути позначена «Таблиця 1» або «Таблиця В.1 », якщо вона наведена в додатку В.

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

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

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

Слово Таблиця указують один раз ліворуч над першою частиною таблиці. Над іншими частинами пишуть слова Продовження таблиці із зазначенням номера  таблиці.

4.4 Оформлення формул і рівнянь

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

Формули в ПЗ варто нумерувати порядковою нумерацією в межах розділу. Номер формули складається з номера розділу й номера формули або рівняння в ньому, розділених крапкою, наприклад, формула (5.3) – третя формула п'ятого розділу. Номер формули вказують на її рівні в дужках у крайньому правому положенні на рядку.

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

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

Приклад оформлення формули:

Час виконання програми процесором оцінюється за допомогою формули оцінки продуктивності:

                                   Т=N*S/F,                                                   (4.1)

 де T – час виконання програми, с;

N – кількість команд, виконуваних у програмі;

 S – середнє число тактів на одну команду;

F тактова частота, Гц.

 

4.5 Оформлення переліків

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

Приклади:

а) мережева модель даних;

б) реляційна модель даних.

або

  •  мережева модель даних;
  •  реляційна модель даних.

Перший варіант краще використовувати при посиланнях. Але іноді, особливо при описі алгоритмів,  краще використати для позначення пунктів списку не букви, а арабські цифри з дужкою. Приклад було наведено у підрозділі 3.6.

Якщо необхідно використати два рівня деталізації, то списки першого рівня позначають літерами, а на другому рівні використовують арабські цифри з дужкою. Списки другого рівня розміщують c відступом вправо відносно місця розташування списків першого рівня.

 4.6 Оформлення посилань

Будь–яке використання даних з літературного або іншого джерела необхідно супроводжувати посиланнями на нього. Посилання на джерела інформації в тексті ПЗ треба вказувати порядковими номерами цих джерел, розташованими між двома квадратними дужками, наприклад,   ... у роботах [1–  7].  Номера джерел вказуються згідно переліку посилань.

Оформлення переліку посилань виконуються за стандартом [7]. Бібліографічні описи в переліку посилань приводять як нумерований список в тому порядку, у якому вони вперше згадувалися в тексті ПЗ. Приклади посилань на деякі типи джерел (книги, стандарти) наведено у переліку до цих вказівок. Приклади посилань на інші типи джерел (патентні документи, статті, звіти, інтернет–ресурси) наведено у  додатку Е.

При посиланнях в межах ПЗ на розділи, підрозділи, пункти, підпункти, ілюстрації, таблиці, формули, рівняння, додатки вказують їх номери. Приклади посилань: “у розділі 4”, “дивися 2.1”, “3.3.4, на рис. 1.3, на рисунку 1.3, у таблиці 3.2, (див табл. 3.2), згідно з формулою (3.2), “у рівняннях (1.23) – (1.25)”, “у додатку Б”.

4.7 Оформлення додатків

 Матеріал, що доповнює текст ПЗ, допускається розміщувати в додатках. Додатками можуть бути, наприклад, графічний матеріал, таблиці формату, що перевищує А4, розрахунки, описи апаратури, блок–схеми алгоритмів і листинги програм.

 Додатки оформляють як продовження ПЗ на наступних його листах. Додатки повинні мати загальну з іншою частиною наскрізну нумерацію сторінок.

У тексті ПЗ на всі додатки мають бути посилання. Додатки розташовують у порядку посилань на них у тексті ПЗ.

 Додатки, як правило, виконують на листах формату А4. Допускається оформляти додатки на листах формату АЗ  та інших, з дотриманням вимог стандарту [7]. У верхній частині листа вказується слово “Додаток” і  буква, що позначає його послідовність.  Додатки позначають заголовними буквами української мови, починаючи з А, за винятком Г, Є, 3, І, Ї, І, О, Ч, Ь. Допускається позначення додатків буквами латинського алфавіту за винятком букв J й О. Нижче окремим рядком вказується заголовок додатку, який записують симетрично відносно тексту із прописної букви. Тобто, якщо додаток читається у альбомній орієнтації, то і позначення додатку, і його заголовок вказується в такій же орієнтації (по широкій стороні листа).

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

4.8 Вимоги до складу й оформлення графічної частини

Відповідно до практики роботи вищої школи, до складу ДП повинна входити графічна частина. Ця частина за рішенням кафедри оформляється, основним чином, на прозорих плівках для проекторів формату А4.

Графічна частина повинна складатися з 6 – 8 листів. Орієнтовний склад листів:

  1.  об'єкт  комп'ютеризації;
    1.  функціональна структура підсистеми;
      1.  інформаційне забезпечення;
        1.  математичне забезпечення;
          1.  програмне забезпечення;
            1.  технічне забезпечення;
              1.  комп'ютерна мережа;
              2.  економічна ефективність підсистеми.

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

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

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

При виконанні графічної частини на листах паперу для креслення формату А1 треба дотримуватися вимог діючих стандартів щодо виконання технічних креслень 2.303– 68, 2.104-68, 2.304-81.

Товщина основної лінії повинна бути в межах від 0,5 до 1,4 мм залежно від величини й складності зображення, а також від формату креслення.

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

Приклад основного напису креслень, схем та реферату наведено на рис. 4.1. При заповненні граф цього напису повинні бути витримані рекомендації стандартів. Відповідно до номерів граф на рис.4.1 треба вказати:

  1.  найменування підсистеми, яке має бути коротким і записуватися у називному відмінку однини; на першому місці має бути іменник, наприклад: підсистема обліку руху матеріальних цінностей;
  2.  кодування для документів проекту;  
  3.  найменування документу, наприклад, схема функціонально-структурна;
  4.  порядковий номер листа;
  5.  загальне число листів.

(2)

(1)

Літера

Маса

Масштаб

Изм

Лист

№ докум

Підпис

Дата

Д

Розроб.

Студент

Перев.

Консульт

Т.контр.

Керівник

Лист (4)

Листів (5)

(3)

ДонНТУ

кафедра АСУ

Група ІУС-___  

Н. контр.

Н.контрол

Затверд.

зав.каф

Рисунок 4.1 –  Приклад виконання основного напису

Документи, що входять до ДП, кодуються за позиціям відповідно до даних студента, наприклад:

номер позиції   1          2           3       4    5     6

   ДП  7.080401 - 06 - 314.003 СФ,

де по позиціях

  1.  ознака  ДП;
  2.  шифр спеціальності;
  3.  останні дві цифри року розробки;
  4.  останні три цифри залікової книжки;
  5.  номер документа в межах ДП, а саме 001 - для ПЗ, 002, 003 і т.д. - для наступних документів, відповідно до їх переліку у відомості об'єму проекту (див. додаток Д);
  6.  дві букви позначення типу креслення або схеми (у даному прикладі - схема функціональна).

Для членів ДЕК дипломник готує комплекти ілюстраційного матеріалу у форматі А4. Цей матеріал має дублювати графічну частину ДП.

5 ОРГАНІЗАЦІЯ ЗАХИСТУ ДИПЛОМНИХ ПРОЕКТІВ ПЕРЕД ДЕК

5.1 Подання дипломного проекту до захисту

Повністю виконану ПЗ студент переплітає за встановленим порядком. Далі студент надає ДП разом з графічною частиною консультантам. На підставі записів у робочому зошиті ті підписують титульний лист ПЗ та роблять відмітки у листі завдання.

Далі ДП, підписаний консультантами, студент надає керівникові. Керівник перевіряє відповідність виконаного проекту завданню і вимогам, підписує титульний лист та готує письмовий відгук.

При необхідності, керівник та консультанти записують свої зауваження та уточнення на листі зауважень.

Далі ДП разом з відгуком надається завідувачеві кафедрою АСУ. Завідувач на підставі представлених йому матеріалів вирішує питання про допуск студента до захисту ДП і робить відповідний запис на титульному листі ПЗ.

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

ПЗ з рецензією, відгуком керівника та довідкою про використання результатів роботи подається секретареві ДЕК напередодні дня захисту.

При поданні матеріалів ДП з порушенням призначених строків кафедра має право перенести строк захисту в межах терміну роботи ДЕК. Якщо при розгляді результатів дипломного проектування кафедра не вважає за можливе допустити студента до захисту ДП, то витяг із протоколу засідання кафедри надається в деканат факультету для рішення питання про відрахування студента з університету. Повторно питання про допуск до захисту може бути порушено тільки після відновлення у складі студентів університету, але не раніше, ніж через 6 місяців після відрахування.

5.2 Вимоги до змісту відгуку керівника та рецензії

5.2.1 Зміст відгуку керівника проекту

На повністю виконаний ДП керівник дає відгук, в якому оцінює роботу студента в період дипломного проектування і надається характеристика виконаної роботи за всіма розділами ДП. У відгуку керівник має оцінити наступні питання:

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

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

5.2.2 Зміст рецензії на  дипломний проект

Основним змістом рецензії мають бути результати всебічного аналізу і оцінки ДП з обов'язковим розкриттям наступних питань:

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

У висновку рецензії зазначається, чи відповідає представлена робота вимогам до дипломних проектів за фахом 7.080401 Інформаційні управляючі системи і технології та оцінюється якість ДП за 4-х бальною системою.

Обсяг рецензії має становити 1–2 сторінки.

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

5.3 Захист дипломних проектів перед ДЕК

До захисту ДП допускаються студенти, які виконали всі вимоги навчального плану і програми навчання за фахом.

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

У день захисту ДП студент повинен представити в ДЕК наступні документи:

  •  залікова книжка;
  •  направлення студента на захист дипломного проекту (форма № В–9.03);
  •  дипломний проект (ПЗ, графічна частина, ілюстраційний матеріал);
  •  відгук керівника;
  •  рецензія.

Для підтвердження наукової і практичної цінності виконаного ДП в ДЕК також представляються додаткові матеріали:

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

Захист ДП проводиться на засіданні ДЕК за участю не менш половини складу комісії.

На підставі подання секретаря ДЕК її голова повідомляє про початок захисту чергового ДП і надає слово студентові. Для усної доповіді за темою ДП студентові надається 10–15 хвилин. Доповідь студента має складатися із трьох частин: вступу, основної частини і висновку.

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

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

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

  •  Після доповіді дипломника зачитується рецензія, а при необхідності – відгук керівника. Студентові надається можливість відповісти на зауваження, дати пояснення, дати аргументовані відповіді на зауваження рецензента. Далі дипломник відповідає на запитання членів ДЕК. При відповідях студент може використовувати графічну частину, макети, ПЗ та демонстраційну версію.

Тривалість захисту одного ДП, як правило, не повинна перевищувати 30 хвилин.

ДЕК оцінює виконану дипломником роботу на підставі представленого ДП, відгуку керівника, рецензії, виступу і відповідей дипломника на запитання. Особлива увага при оцінюванні приділяється використанню ДП або окремих його частин на підприємстві, організації або в науково–дослідній роботі кафедри.

Результати захисту ДП визначаються за 4-х бальною системою. При визначенні оцінки проекту до уваги береться рівень теоретичної й практичної підготовки студента.

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

Результати захисту ДП оголошуються у той же день після оформлення протоколів засідання ДЕК.

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

Студентові,  який має диплом бакалавра з відзнакою, склав іспити, заліки, курсові проекти і роботи з оцінкою “відмінно” не менш, ніж з 75% всіх дисциплін навчального плану підготовки спеціаліста, а з інших дисциплін – з оцінкою “добре” та захистив дипломний проект з оцінкою “відмінно”, видається диплом спеціаліста з відзнакою.

За результатами захисту ДП, участі студента у науково–дослідній роботі на протязі періоду навчання, ДЕК може рекомендувати випускника для вступу до аспірантури безпосередньо після закінчення університету.

Якщо захист ДП визнається незадовільним, ДЕК визначає, чи може студент представити до повторного захисту той же проект із доробкою, обумовленою комісією, або ж має виконати проект за новою темою, яку визначить кафедра.

Студент, що одержав незадовільну оцінку при захисті ДП, відраховується з університету. Йому видається академічна довідка встановленого зразка.

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

ПЕРЕЛІК ПОСИЛАНЬ

  1.  ГОСТ 34.601–90. Автоматизированные системы. Стадии создания. В кн.: Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. М.: Комитет стандартизации и метрологии СССР,1991. – с.45-52.
  2.  ГОСТ 34.602–89. Техническое задание на создание автоматизированной системы. В кн.: Информационная технология. Комплекс стандартов и руководящих документов на АС. М.: Комитет стандартизации и метрологии СССР,1991. – с.15-29
  3.  РД 50–34.698–90. Автоматизированные системы. Требования к содержанию документов. В кн.: Информационная технология. Комплекс стандартов и руководящих документов на АС. М.: Комитет стандартизации и метрологии СССР,1991. – с.66-104.
  4.  Закон України “Про вищу освіту” (Із змінами, внесеними згідно із Законом № 380-IV від 26.12.2002). Відомості Верховної Ради, 2002, № 20, с.134.
  5.  “Положення про освітньо–кваліфікаційні рівні”. Постанова Кабінету Міністрів України від 20.01.1998 р. за № 65.
  6.  “Положення про організацію навчального процесу у вищих навчальних закладах”, затверджене наказом Міністерства освіти України від 2 червня 1993 року, № 161. – URL: http:// donntu.edu.ua/russian/metod/kerivnimateriali/2.doc
  7.  ДСТУ 3008–95. Государственный стандарт Украины “Документация. Отчеты в сфере науки и техники. Структура и правила оформления”. – К.: Госстандарт Украины, 1995. – 36 с.
  8.  ГОСТ 19.701–90 (ИСО 5807-85). Схемы алгоритмов, программ, данных и систем. Госстандарт СССР, 1990. –  20 с.
  9.  Стандарт ДонГТУ “Структура и правила оформления документов по всем видам учебной работы” / Сафьянц С.М. и др. – Донецк: ДонГТУ, 1999. – 44 с.
  10.   Наскрізна програма практик для студентів спеціальності 07.080401 “Інформаційні управляючі системи і технології”(ІУС). / Укладачі: Спорихін В.Я, Блощицький В.П., Жукова Т.П., Омельченко А.А. – Донецьк: ДонНТУ 2005. – 40 с.

Додаток А

Форма першої сторінки обкладинки

МІНІСТЕРСТВО ОСВІТИ і науки  УКРАЇНИ

ДОНЕЦЬКИЙ  НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

Кафедра “Автоматизовані системи управління”

Дипломний проект

Тема: “Спроектувати          (назва системи / підсистеми)                        ” _____________________________________________________________

Пояснювальна записка до дипломного проекту

ДП–7.080401–**–***.*** ПЗ

Дипломник  Іванов І.І.

НТБ ДонНТУ Вик. 200__ р.

    Інв. № _______

Дип. записка _____екз.

Креслення _____ листа (ів)

фак–т  КІТА  гр. ІУС-__

Донецьк, 200__ р

Додаток Б

Форма титульного листа пояснювальної записки

мІНІСТЕРСТВО ОСВІТИ і науки  УКРАЇНИ

ДОНЕЦЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

                             Допущено до захисту                   Факультет  _КІТА_

Кафедра   "Автоматизовані системи управління"

                         Завідувач  кафедри          __________________     (____Скобцов Ю.О.____)

                                          (підпис, дата)                                         (П.І.Б.)

                      ДИПЛОМНИЙ ПРОЕКТ _ДП–7.080401–**–***.*** ПЗ

                                                                                  (позначення)

Тема: “Спроектувати                         (назва системи / підсистеми_)

________________________________________________________

Виконавець_____________________         студент __________________________

                                               (підпис, дата)                                                         (прiзвище, ім’я, по-батькові.)

                     група    _ІУС_- ____________________

          Керівник       __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

          Консультанти: 

  __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

  __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

  __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

  __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

  __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

 

  Нормоконтролер: __________________________                               __________________ 

                                                 (підпис, дата)           (ПІБ)

Донецьк, 200__ р

Додаток В

Форма листа завдання з календарним планом

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

ДОНЕЦЬКИЙ НАЦІОНАЛЬНИЙ  ТЕХНІЧНИЙ УНІВЕРСИТЕТ

Факультет_________КІТА______________ Кафедра__________АСУ_____________

Спеціальність 7.080401 "Інформаційні управляючі системи і технології"

      ЗАТВЕРДЖУЮ:

      Зав. кафедри _________Скобцов Ю.О.

               (П.І.Б)

      "___" _____________________200__ р.

ЗАВДАННЯ

на дипломний проект студентові

_________________________________________

(прiзвище, ім’я, по батькові)

1. Тема проекту: Спроектувати                         (назва системи / підсистеми_)

____________________________________________________________________

_в умовах (назва підприємства або установи)____________________________

затверджена наказом по університету від “                         200  р    №_______

2. Термін здачі студентом закінченого проекту _________________________

3. Вхідні дані до проекту (роботи) матеріали курсового проекту, переддипломної практики, звіт з НДРС, ДСТУ, додаткова література_________                   

4. Зміст розрахунково–пояснювальної записки (перелік питань, що підлягають розробці) ___________________________________________________________

____________________________________________________________________

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5. Перелік графічного матеріалу (з точною вказівкою обов’язкових креслень) ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

6. Консультанти проекту, із вказівкою розділів проекту, з яких проводились консультації

Розділ

Консультант

Підпис, дата

Завдання видав

Завдання прийняв

Технічне завдання

Інформаційне забезпечення 

Математичне забезпечення

Програмне забезпечення 

Технічне забезпечення

Комп'ютерна мережа

Економічний розрахунок

7. Дата видачі завдання___________________________________________________________

  Керівник              _____________

              (підпис)

                          Завдання прийняв до виконання   _____________

               (підпис)

КАЛЕНДАРНИЙ ПЛАН

№ п/п

Назва етапів дипломного проекту

Термін виконання етапів проекту

Примітка

1.

Технічне завдання   

2.

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

3.

Математичне забезпечення

4.

Інформаційне забезпечення 

5.

Програмне забезпечення 

6

Технічне забезпечення

7

Комп'ютерна мережа

8

Економічний розрахунок

9

Оформлення ПЗ

10

Оформлення графічного матеріалу

Студент–дипломник           ___________________

                                                                        (підпис)

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

                                                                           (підпис)

Додаток Д

Форма відомості обсягу дипломного проекту

ВІДОМІСТЬ ОБСЯГУ ДИПЛОМНОГО ПРОЕКТУ

Формат

Позначення  документу

Найменування

Кількість листів

Шифр

1

А4

ДП–7.080401–**–***.001 ПЗ                                                                                             

Пояснювальна записка

***

2

А4

ДП–7.080401–**–***.002 ОК                                                                                             

Об'єкт комп’ютеризації

1

3

А4

ДП–7.080401–**–***.003 СФ                                                                                             

Функціональна схема

1

4

А4

ДП–7.080401–**–***.004МФ                                                                                             

Фізична модель даних

1

5

А4

ДП–7.080401–**–***.005 АР                                                                                             

Алгоритм роботи підсистеми

1

6

А4

ДП–7.080401–**–***.006 СМ                                                                                             

Схема комп’ютерної мережі.

1

7

А4

ДП–7.080401–**–***.007 СП                                                                                             

Структура програм-ного забезпечення

1

8

А4

ДП–7.080401–**–***.008 ЕР                                                                                             

Економічні розрахунки

1

Додаток Е

Приклади бібліографічного опису посилань

Патентні документи

11.А.С.№ 1390355 СССР, МКИ3 Е 21 С 35/24. Способ регулирования скорости подачи комбайна/ Н.И.Чичикало,И.М.Кубрак, В.В.Бондарчук, В.П.Блощицкий и др. – № 4109418/22–03; Заявлено 04.06.86., Опубл. 23.04.88. Бюл. № 15. – 2 с.

Звіти про науково – дослідні роботи

12.Разработка научно-методических основ построения и использования компьютерных информационных, управляющих систем и технологий для научной и учебной работы: Отчет о НИР (заключительный) /Донецк.нац.техн. ун-т (ДонНТУ); Руководитель В.Я. Спорыхин. – Н-31-2000.– Донецк, 2005. –236 с.

 Статті з журналів, матеріалів конференцій, збірок наукових праць

13.Лысенко Ю.А., Шевченко А.Ю. Исследование процессов ионизации комплексов трехфтористого бора в простых эфирах // Журн. общей химии, 1984.  – Т. 54,  вып.12.  –  с. 265–269.

14. Воропаєва В.Я. Проблеми організації телекомунікаційної складової дистанційної освіти// Наукові праці Донецького національного технічного університету. Серія:  “Обчислювальна техніка та автоматизація”.Випуск 74 /Редкол.:Башков Є.О.(голова) та ін.  – Донецьк: ДонНТУ, 2004. – с.181 – 185.

15. Солдатенкова К.Ю. Аналіз функціонування виробничо – технічного відділу в умовах ЗАТ “Інформаційні технології”//  Збірка студентських наукових праць факультету “Комп’ютерні інформаційні технології і автоматика”  Донецького національного технічного університету. Випуск 2 . – Донецьк: ДонНТУ, 2004. – с.238 – 241.

Інтернет–ресурси

16.Кузнецов С. Д. Проектирование и разработка корпоративных инфор-мационных систем. Центр Информационных Технологий, 1998. – URL: http://www.citforum.ru/cfin/prcorpsys/

МЕТОДИЧНІ ВКАЗІВКИ

ДО ДИПЛОМНОМУ ПРОЕКТУВАННЯ

для студентів спеціальності 7.080401 Інформаційні

управляючі системи і технології (ІУС)

                             Укладачі: професор Спорихін В. Я.

                                                  професор Лаздинь С.В.

                                                  доцент Жукова Т.П.

                                                  доцент Шатохін П.О.

                                                  ст. викл. Блощицький В.П.


 

А также другие работы, которые могут Вас заинтересовать

78849. Научное, ненаучное, псевдонаучное знание 30.5 KB
  Научное ненаучное псевдонаучное знание. Научное знание система знаний о законах природы общества мышления. Научное знание составляет основу научной картины мира и отражает законы его развития. Научное знание: является результатом постижения действительности и когнитивной основой человеческой деятельности; социально обусловлено; и обладает различной степенью достоверности.
78850. Метатеоретический уровень научного знания 26.5 KB
  мета за после это теория о теории: объектом научного анализа для метатеории выступает сама теория. Метатеоретический подход не просто реорганизует научное знание является не только способом научного анализа теории но производит в ней сдвиги содержательного порядка порождает новое знание. Рефлексия является своеобразным способом развития самого содержания знания одним из важных путей разработки теории Дело в том что плодотворен сам по себе выход за пределы теории отстраненный взгляд на нее. На основе метатеории в процессе...
78852. Философские основания науки 27 KB
  Философские основания науки Предисловие: Философское основание науки представляет особой один из элементов философии науки направление в философии изучающее научную деятельность ее особенности и характеристики; ее цель – устанавливать правильность научных суждений и теорий и объяснять место и роль науки в современной культуре наряду с теоретическим и эмпирическим знанием. Философские основания науки. Философские основания науки. Функции функция философского обоснования: Любая новая идея для того чтобы стать либо частью картины мира...
78853. Структура эмпирического знания. Проблема факта 28.5 KB
  Проблема факта Эмпирические факты образуют базис на который опираются научные теории. Факты фиксируются в языке науки в высказываниях типа: более половины опрошенных в городе недовольны экологией городской среды и т. Вернадский: эмпирические факты хлеб науки. Проблема факта: Эмпирические факты содержат не только информацию об изучаемых явлениях но и как правило включают ошибки наблюдателя и т.
78854. Структура теоретического знания 29 KB
  Теоретический уровень научного познания как и эмпирический имеет ряд подуровней среди которых можно выделить следующие по степени общности: а аксиомы теоретические законы; б частные теоретические законы описывающие структуру свойства и поведение идеализированных объектов; в частные единичные высказывания утверждающие нечто о конкретных во времени и пространстве состояниях свойствах и отношениях некоторых идеализированных объектов 2 вида научных законов: 1Универсальные и частные законы. Универсальными принято называть законы...
78855. Функции научной теории 14.81 KB
  Функции научной теории. Объяснение и предсказание окружающих нас вещей и явлений представляет собой важнейшую функцию науки в целом и научной теории в частности. Основные функций теории можно отнести следующие. Методологическая функция на базе теории формулируются многообразные методы способы и приемы исследовательской деятельности.
78856. Методы научного познания и их классификация 41.5 KB
  Методы научного познания и их классификация Метод систематизированная совокупность шагов действий кые необходимо предпринять чтобы решить определенную задачу или достичь определенной цели. Методы эмпирического познания Методы теоретического познания. Моделирование от лат – образец мира – метод при ком исследуемый объект оригинал замещается другим модель специально созданным для его изучения. Рефлексия – основной метод метатеоретического познания в науке познание обращенное ученым на самого себя.
78857. Ценности и их роль в познании 35.5 KB
  Ценности и их роль в познании Философское учение о ценстях и их природе называется аксиологией. Эпоха Возрождения выдвигает на первый план ценсти гуманизма. В Новое время развитие науки и новых общественных отношений во многом определяют и основной подход к рассмотрению предметов и явлений как ценстей. Кант впервые употребляет понятие ценсти в специальном узком смысле.