1.4.2. Вимоги до супроводжувальної документації
Текст супроводжувальної документації набирається на комп’ютері шрифтом Times New Roman 14 пт через 1,5 інтервали. Розміщення – книжкове.
Поля: зліва – не менше 2,5 см, решта полів – не менше 1,5 см. Вирівнювання – по ширині аркуша.
Відступ першого рядка абзацу – 1,27 см. Нумерація сторінок – наскрізна в усій роботі. Номери сторінок ставляться від центру. Формат: - 7 -.
На титульному аркуші та листі затвердження номери не ставляться, хоча самі аркуші враховуються у загальній кількості сторінок.
1.5. Стадії та етапи розробки
Таблиця 1
Стадії та етапи розробки
№ п/п |
Назва етапів кваліфікаційної роботи |
Термін виконання етапів роботи |
Примітка |
1 |
Одержання технічного завдання |
24.11.2012р. |
|
2 |
Аналіз літератури |
22.12.2012р. |
|
3 |
Ознайомлення з роботою підприємства |
03.01.2013р. |
|
4 |
Розробка інтерфейсу |
20.01.2013р. |
|
5 |
Створення баз даних Paradox |
30.01.2013р. |
|
6 |
Реалізація АС “Автотехсервіс” |
15.02.2013р. |
|
7 |
Реалізація обміну файлами |
30.02.2013р. |
|
8 |
Розробка довідки |
15.03.2013р. |
|
9 |
Тестування та відлагодження програми |
20.04.2013р. |
|
10 |
Оформлення програмної документації |
05.05.2013р. |
|
11 |
Представлення готової роботи |
08.05.2013р. |
|
12 |
Захист роботи |
згідно розкладу |
|
1.6. Порядок контролю і приймання
Програмне забезпечення повинне бути випробуване та протестоване виробником на наявність помилок.
Порядок контролю і приймання проекту полягає у наступному:
Перевірка правильного функціонування програми керівником проекту.
Перевірка відповідності стандартам оформлення документації.
Перевірка правильного оформлення програмної документації керівником проекту.
Попередній захист курсової роботи.
Проходження нормоконтролю роботи.
Практична частина
2. Архітектура, функціональні та технічні показники
2.1. Призначення та область застосування
Експлуатаційне призначення цієї розробки - у даній роботі необхідно розробити пропозиції, щодо автоматизації автотехсервісу, розробити модель програмного продукту, призначеного для автоматизації процесу підбору запчастин для ремонту і попередньої опису по виконаним роботам автомобілів. Розроблена модель програмного продукту повинна розраховувати вартість запчастин до конкретного автомобіля використовуючи наявну базу даних по запасним частинам, а також розраховувати економічну вартість проведених робіт по ремонту автомобіля для клієнта.
2. 2. Опис та обґрунтування обраної архітектури
Для даного проекту була вибрана модульна архітектура, оскільки вона є досить зручною для розроблення програмного продукту. Кожне вікно програми працює з функціями відповідного модуля (рис. 2.2.1).
Збереження даних в БД
Відсилання збережених даних Адміністратору
Рис. 2.2.1. Блок-схема роботи програми