На головну

Розділ 2. Технічне завдання

2.1 Найменування та область застосування розробки

Як предметної області може виступати підрозділ підприємства, фірми, об'єднання і т.д., або окремий вид діяльності, що протікає в ньому.

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

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

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

Цілями обґрунтування необхідності створення інформаційної системи, можна навести такі:

§ зниження вартості продукції;

§ збільшення кількості або асортименту;

§ скорочення циклу розробка нових товарів і послуг, вихід на ринок;

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

Опис моделей бізнес-процесів об'єкта автоматизації

Розгляд досліджуваного об'єкта передбачає побудову двох видів моделей. На цьому етапі необхідно побудувати моделі «як є» ( «as is»), що відображають існуючий на момент обстеження стан справ в предметної області і описують, яким чином функціонує даний об'єкт. Побудова моделей бізнес-процесів предметної області може бути виконано за допомогою різних методик, які відрізняються підходами до моделювання. Прийнято розрізняти методики об'єктні і функціональні (структурні).

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

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

Об'єктно-орієнтований підхід передбачає виділення класів об'єктів і визначення дій, в яких беруть участь об'єкти. При цьому розрізняють пасивні об'єкти, над якими виконуються дії, і активні об'єкти, які здійснюють ці дії. Такий підхід дозволяє виділяти операції над об'єктами і вирішувати завдання доцільності існування самих об'єктів.

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

Для проведення моделювання розроблені різні методології та відповідні інструментальні засоби. Методології функціонального моделювання (діаграми потоків даних DFD, структурні діаграми процесів IDEF0, ARIS) орієнтовані на відображення послідовності функцій. При їх використанні важко визначити конкретні альтернативи процесів і побачити схему взаємодії об'єктів. Об'єктні моделі, навпаки, відображають лише узагальнену схему взаємодії об'єктів без деталізації послідовності виконання функцій. Методології об'єктно-орієнтованого підходу відображають об'єкти, функції і події, при яких об'єкти ініціюють виконання конкретних процесів. Як мова для опису моделей при об'єктно-орієнтованому підході виступає UML (Unified Modeling Language). UML стосовно бізнес моделювання може включати наступні діаграми: Activity-діаграми, Class-діаграми, Component-діаграми, Collaboration-діаграми, Sequence-діаграми, Use Case-діаграми, Deployment-діаграми, Statechart-діаграми.

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

Визначення недоліків існуючої системи обробки інформації

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

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

§ можливість появи помилок при складанні документів;

§ висока трудомісткість обробки інформації;

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

§ недосконалість організації збору та реєстрації вихідної інформації;

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

2.2 Підстава для розробки

Що послужило причиною для створення даного програмного продукту. Які проблеми необхідно вирішити зі створенням даної розробки.

2.3 Цілі і призначення розробки

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

В якості завдань проектування можна виділити наступні:

§ створення графічного інтерфейсу користувача;

§ максимальна простота у використанні;

§ використання відкритих програмних систем при розробці АІС;

§ забезпечення взаємодіями з різними серверами баз даних;

§ зменшити навантаження на мережу за рахунок використання отсоединенного механізму доступу до даних і т.д.

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

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

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

§ необхідна гнучка система розмежування доступу відповідно до правами користувачів, а також надійний захист від несанкціонованого доступу;

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

§ програмне забезпечення має забезпечувати одночасну роботу до 100 користувачів з даними по локальної обчислювальної мережі і Internet і т.д.

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

§ ведення бази співробітників;

§ можливість ведення декількох організацій в одній програмі;

§ створення карток співробітників з розширеним особистісним і професійним урахуванням;

§ можливість формування наказів на базі шаблонів Word;

§ прийом на роботу нових співробітників;

§ розрахунок відпусток, стажу і т.д.

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

2.4 Джерело розробки

В даному розділі джерело розробки - це джерело розробки технічного завдання.

Повинні бути перераховані документи та інформаційні матеріали (техніко-економічне обґрунтування, звіти про закінчені науково-дослідні роботи, інформаційні матеріали на вітчизняні, закордонні системи-аналоги та ін.), На підставі яких розроблялося ТЗ і які повинні бути використані при створенні системи.

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

2.5 Постановка завдання

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

На цьому етапі необхідно побудувати моделі «як повинно бути» ( «to be»), які відображають зміни бізнес процесів з урахуванням впровадження інформаційної системи.

2.6 Алгоритм рішення

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

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

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

2.7 Вимоги до системи

В даному розділі вказують:

· Вимоги до структури та функціонування системи;

· Вимоги до захисту інформації від несанкціонованого доступу;

· Вимоги щодо збереження інформації пріаваріях;

· Вимоги до захисту від впливу зовнішніх впливів;

У вимогах до структури та функціонування системи призводять:

· Перелік підсистем, їх призначення та основні характеристики, вимоги до числа рівнів ієрархії і ступеня централізації системи;

· Вимоги до способів і засобів зв'язку для інформаційного обміну між компонентами системи;

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

· Вимоги до режимів функціонування системи;

· Вимоги по діагностуванню системи;

· Перспективи розвитку, модернізації системи.

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

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

У вимогах до засобів захисту від зовнішніх впливів призводять:

· Вимоги до радіоелектронної захисту коштів ПО;

· Вимоги щодо стійкості, стійкості і міцності до зовнішніх впливів (середовищі застосування).

2.8 Вимоги до надійності

У вимоги до надійності включають:

· Склад і кількісні значення показників надійності для системи в цілому або її підсистем;

· Перелік аварійних ситуацій, за якими повинні бути регламентовані вимоги до надійності, і значення відповідних показників;

· Вимоги до надійності технічних засобів і програмного забезпечення;

· Вимоги до методів оцінки і контролю показників надійності на різних стадіях створення системи відповідно до чинних нормативно-технічних документів,

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

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

Для інформаційного забезпечення системи приводять вимоги:

· До складу, структури і способів організації даних в системі;

· До інформаційного обміну між компонентами системи;

· До інформаційної сумісності із суміжними системами;

· По застосуванню систем управління базами даних;

· До структури процесу збору, обробки, передачі даних в системі і представлення даних;

· До захисту даних від руйнувань при аваріях і збоях в електроживленні системи;

· До контролю, зберігання, оновлення та відновлення даних.

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

Для програмного забезпечення системи приводять перелік покупних програмних засобів, а також вимоги:

· До незалежності програмних засобів і операційного середовища;

· До якості програмних засобів, а також до способів егообеспеченія і контролю;

· По необхідності узгодження розроблених нових програмних засобів з фондом алгоритмів і програм.

Для технічного забезпечення системи приводять вимоги:

· До видів технічних засобів, в тому числі до видів комплексів технічних засобів, програмно-технічних комплексів та інших комплектуючих виробів, допустимих до використання в системі;

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

2.10 Естетичні та ергономічні вимоги

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

2.11 Вимоги до стандартизації та уніфікації

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

· Стандартних, уніфікованих методів реалізації функцій (завдань) системи,

· Поставляються програмних засобів,

· Типових математичних методів і моделей,

· Типових проектних рішень,

· Уніфікованих форм управлінських документів, встановлених ГОСТ 6.10.91,

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

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



СТРУКТУРА ДИПЛОМНОГО ПРОЕКТУ | Розділ 4. Керівництво програміста

МЕТА ТА ЗАВДАННЯ ДИПЛОМНОГО ПРОЕКТУ | Розділ 5. Керівництво користувача | ОФОРМЛЕННЯ ДИПЛОМНОГО ПРОЕКТУ | Шифр розділу | Перерахування в тексті | Ілюстрації в тексті | структура таблиці |

© um.co.ua - учбові матеріали та реферати