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–го запису	Кількість записів	Об'єм записів	Загальний об'єм
Усього

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