Порядок контролю та прийому системи.

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

4.1 Вимоги до системи загалом:

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

4.1.2 Вимоги до персоналу (чисельність користувачів, кваліфікація, режим роботи, порядок підготовки) – 1 користувач, що має добрі знання ПК та Internet (керівництво користувачу додається) та є робінтиком технікума.

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

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

 

4.2 Вимоги до функцій (по підсистемам).

4.2.1 Перелік завдань, що підлягають автоматизації:

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

- пошук потрібної інформації.

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

4.2.3 Перелік і критерії відмов – інформація, яка введена в строку пошуку відсутня, або введена невірно.

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

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

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

4.3.3 Лінгвістичному (мови програмування, мови взаємодії користувачів з системою, системи кодування, мови введення-виводу) – розробка системи відбувалась за допомогою HTML, jQuery та CSS, мова взаємодії системи з користувачами – російська, мова вводу-виводу інформації – російська, регіональні стандарти часу та дати відповідають українським за Києвом.

 

 

4.3.4 Програмному (незалежність програмних засобів від платформи, якість програмних засобів і способи його контролю, використання фондів алгоритмів і програм) – мова, за допомогою якої «будувалася» система дозволяє легко розширювати проект.

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

4.3.5 Методичному (склад нормативно-технічної документації) – планується створення керівництва користувача.

 

5. Склад та зміст робіт по створенню системи.

5.1 Перелік стадій та етапів робіт – весь період створення програмного продукту планується розділити на 5 етапів: аналіз предметної області, проектування ПП, реалізація ПП, впровадження та супровід ПП, які відповідають життєвому циклу проекту.

5.2 Строки виконання – етапи з 1 по 4 планується виконати до 10.06.10, 5-й – етап виконується до моменту зняття ПП з експлуатації (припинення використання).

5.3 Склад організацій – виконавців робіт: керівник дипломної роботи –Кревенченко Ю.А., виконавець дипломної роботи – Зубарець М.В.

5.4 Вид та порядок експертизи технічної документації: експертизу технічної документації проводить керівник дипломної роботи, контроль за виконанням відповідних розділів – консультант з економічної частини Герасимова Л.А, консультант з охорони праці – Поліщук С.О.; пояснювальна записка оформлюється відповідно до ДГСТ та вимог до оформлення дипломних робіт за спеціальність 5.080406, викладених у відповідних методичних вказівках, нормо контроль проводиться головою циклової комісії Клименко О.Г.

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

Порядок контролю та прийому системи.

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

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

6.3 Статус приймальної комісії: дипломний керівник – Кревенченко Ю.А., голова циклової комісії – Клименко О.Г., зав.відділенням – Поліщук С.О.

7. Вимоги до складу робіт по підготовці об’єкту автоматизації до вводу системи в дію:

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

7.2 Зміни в об’єкті автоматизації: покращення параметрів ПК, на якому буде встановлено ПП, встановлення додаткового програмного забезпечення, яке потрібно для функціонування ПП.

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

Вимоги до документування.

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

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

Джерела розробки.

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

1) Bear Bibeault and Yehuda Katz «jQuery in Action»

2) Марка Пилгрима «Погружение в HTML5»

3) Бен Хеник «HTML и СSS путь к совершенству»