Створення онлайн-сервісу з обліку платних послуг вищого навчального закладу

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ВСТУП

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

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

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

Найбільш поширені кредитні системи, що дозволяють використовувати в Мережі звичайні кредитні картки. Технологія кредитних карт, що обслуговує розрахунки по пластикових картах, представлена такими системами, як Assist і CyberPlat.

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

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

Глобальна мережа Internet зробила електронну комерцію доступної для фірм будь-якого масштабу. Якщо раніше організація електронного обміну даними вимагала помітних вкладень у комунікаційну інфраструктуру й була по плечі лише великим компаніям, то використання Internet дозволяє сьогодні вступити в ряди "електронних торговців" і невеликим фірмам. Електронна вітрина в World Wide Web дає будь-якої компанії можливість залучати клієнтів із усього миру. Подібний on-line бізнес формує новий канал для збуту - "віртуальний", що майже не вимагає матеріальних вкладень. Якщо інформація, послуги або продукція (наприклад, програмне забезпечення) можуть бути поставлені через Web, то весь процес продажу (включаючи оплату) може відбуватися в on-line режимі.

На сьогоднішній день домінуючим платіжним засобом при on-line покупках є кредитні картки. Однак на сцену виходять і нові платіжні інструменти: смарт- карти, цифрові гроші (digital cash), мікроплатежі й електронні чеки.

Електронна комерція містить у собі не тільки on-line транзакції. В область, охоплювану цим поняттям, необхідно включити й такі види діяльності, як проведення маркетингових досліджень, визначення можливостей і партнерів, підтримка зв'язків з постачальниками й споживачами, організація документообігу та ін. Таким чином, електронна комерція є комплексним поняттям і містить у собі електронний обмін даними як одну зі складових.

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

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

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

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

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

1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ І ПОСТАНОВКА ЗАВДАННЯ

1.1 Аналіз предметної області

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

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

На даному етапі виділяється два основні способи оплати:

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

- Електронні кошти - це грошові зобов'язання емітента в електронному вигляді, які знаходяться на електронному носії у розпорядженні користувача. Такі грошові зобов'язання відповідають таким трьом критеріям [21]:

- Фіксуються і зберігаються на електронному носії.

- Випускаються емітентом при отриманні від інших осіб грошових коштів в обсязі не меншому, ніж емітована грошова вартість.

- Вживати, як засіб платежу іншими (крім емітента) організаціями.

1.2 Платіжна система Інтернет

проектування реляційний обліковий споживач

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

- Дебетові (працюючі з електронними чеками та цифрової готівкою);

- Кредитні (працюючі з кредитними картками).

1.2.1 Дебетові системи

Дебетові схеми платежів побудовані аналогічно звичайним грошовим і чекових.

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

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

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

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

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

- По-перше, виписуючи паперовий чек, платник ставить свою справжню підпис, а в онлайновому варіанті - підпис електронна;

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

1.2.2 Процесінг платіжних карт

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

1.3 Електронна комерція і маркетинг

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

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

Глобальна мережа Інтернет зробила електронну комерцію доступної для фірм будь-якого масштабу. Якщо раніше організація електронного обміну даними вимагала помітних вкладень у комунікаційну інфраструктуру й була по плечі лише великим компаніям, то використання Internet дозволяє сьогодні вступити в ряди "електронних торговців" і невеликим фірмам. Електронна вітрина в World Wide Web дає будь-якої компанії можливість залучати клієнтів із усього миру. Подібний on-line бізнес формує новий канал для збуту - "віртуальний", що майже не вимагає матеріальних вкладень. Якщо інформація, послуги або продукція (наприклад, програмне забезпечення) можуть бути поставлені через Web, то весь процес продажу (включаючи оплату) може відбуватися в on-line режимі.

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

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

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

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

Зворотний зв'язок надається різними способами, такими як: коментування, оцінювання системи, прямі запитання.

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

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

2. ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

2.1 Побудова Use Case діаграми

Дана система має кілька ролей: не авторизований користувач, авторизований користувач та адміністратор.

Не авторизований користувач має можливість:

- перегляд списку послуг;

- перегляд списку видів оплати;

- оцінювання послуг та видів оплати

- коментування послуг та видів оплати;

- перегляд інформації про заклад який надає послуги;

- використовувати пошук за послугами;

- реєстрація;

- авторизація.

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

Авторизовані користувач має ті ж можливості, що й не авторизовані, а також:

- зберігати дані у своєму обліковому записі;

- сплачувати послуги

- просмотр історії оплат

- видалення облікового запису.

На рисунку 2.2 показана Use Case діаграма для авторизованого користувача, за винятком можливостей, показаних на рисунку 2.1.



Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.1 - Use Case діаграма для не авторизованого користувача

Найширшою в плані можливостей являється роль адміністратора. Адміністратор має доступ в адміністративну (закриту для всіх інших користувачів) частину сайту, в якій є:

- змінювати налаштування підключення до бази даних;

- виробляти додаткові (не заплановані в звичайній роботі програми) копії даних;

- встановлювати дані, як частково, так і повністю;

- блокувати користувачів;

- управління списком послуг

- управління списком видів оплати

- статистика сплати за послуги

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.2 - Use Case діаграма для авторизованого користувача

2.2 Проектування розділів системи

2.2.1 Проектування розділу послуг

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

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

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

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

Загальна структура даного розділу відображено в рисунку 2.3.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.3 - Загальна структура розділу послуг

2.2.2 Проектування розділу методів оплати

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

Кожний метод може бути прокоментований будь-яким користувачем, у тому числі й анонімним.

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

2.3 Проектування підсистеми менеджменту

Головною особливістю системи є можливість управління обліком послуг у ВНЗ. В першу чергу адміністратор може керувати послугами та методами оплати.

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

При створенні нової послуги можна також віднести її до категорії, або створити нову категорії, якщо її не існує.

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

Таблиця 2.1 - Основні шаги створення послуги

№ шагу	Опис	Рівень доступу	Відміна дій	Обов'язковість
1	Заповнення основної інф-ії	Тільки творець	Редагування та видалення	Так
2	Заповнення денальною інформацією	Тільки творець	Редагування та видалення	Ні
3	Вибір категорії	Тільки творець	Редагування та видалення	Так.
4	Встановлення дати з якої до якої ця послуга будет доступна	Тільки творець	Редагування та видалення	Ні. За замовчуванням тимчасове обмеження не буде встановлення.
5	Встановлення доступних методів оплат	Тільки творець	Редагування та видалення	Так
6	Активна	Тільки творець	Редагування	Ні. За замовчуванням послуга завжди активна

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

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

На рисунку 2.5 показано життєвий цикл послуги.



Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.5 - Життєвий цикл послуги

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

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

2.4 Проектування бази даних

2.4.1 Організація сутностей і зв'язків між ними

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

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

- логін - ім'я користувача, необхідне для реєстрації в системі;

- пароль користувача;

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

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

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

Для надання додаткових можливостей всередині системи запроваджуватися система ролей. Основними ролями являються:

- звичайний користувач - дана роль всім користувачам за замовчанням;

- модератор методів оплати - має можливість модерувати заданий розділ;

- модератор послуг - має можливість модерувати розділ послуг;

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

Користувачі можуть сплачувати за послугу та проявлятися свою статистику

Спрощена схема сутностей пов'язаних з користувачами і зв'язків між ними показано на рисунку 2.6.

Рисунок 2.6 - Спрощена схема призначена для користувача системи

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

Зв'язки сутностей, пов'язаних з секцією «методи оплати» та можливістю коментування показані на рисунку 2.8.

Рисунок 2.7 - Сутності розділу послуг і зв'язку між ними.

Рисунок 2.8 - Основні сутності для методів оплати і зв'язку між ними.

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

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

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

Рисунок 2.9 - Основні сутності послуг, методів оплати для відображення звітів.

2.4.2 Побудова схеми реляційної бази даних

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

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

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

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

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

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

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

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

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

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

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

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

- Оскільки SQL-запит, що вибирає дані подання, зафіксований на момент його створення, СУБД отримує можливість застосувати до цього запиту оптимізацію чи попередню компіляцію, що позитивно позначається на швидкості звернення до подання, в порівнянні з прямим виконанням того ж запиту з прикладної програми: Представления скрывают от прикладной программы сложность запросов и саму структуру таблиц БД. Когда прикладной программе требуется таблица с определённым набором данных, она делает простейший запрос из подготовленного представления. При этом даже если для получения этих данных требуется чрезвычайно сложный запрос, сама программа этого запроса не содержит.

Загальна спрощена схема бази даних показана на рисунку 2.10.

Рисунок 2.10 - Спрощена схема бази даних системи

3. РЕАЛІЗАЦІЯ СИСТЕМИ

3.1 Вибір засобів реалізації

Для реалізації даної системи було прийнято рішення використовувати зв'язку програмного забезпечення, що вже давно є стандартом де-факто для більшості інтернет проектів, - це Apache+PHP+MySQL. Перевагами даного вибору є безкоштовність, адже все програмне забезпечення розповсюджується за ліцензією GPL(******), висока продуктивність, що дозволяє не сумніватись, що задачі будуть виконуватись швидко і без збоїв, розвинена система підтримки, адже кожен компонент має розвинену систему сторонніх розробників, що постійно знаходять помилки, збільшують продуктивність та виправляють помилки в системі безпеці та рапортують про це головним розробникам компонентів.

Цей програмний продукт був реалізований у вигляді веб-проекту на мові серверних скриптів PHP. Для відповідності патерну програмування MVC - було використано бібліотеку Smarty, що як і інші компоненти, розповсюджується безкоштовно, та дозволяє відділити зовнішній вигляд(HTML-розмітку) від логіки скриптів(PHP-скрипти).

Під час реалізації проекту використовувалась модель «клієнт-сервер», що є найбільш розповсюдженою для розробки веб-сайтів. Сховищем даних виступає MySQL 5.1.41. Це було зроблено через декілька причин:

- ця версія - найбільш нова із стабільних версій цієї програми;

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

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

Розглянемо життєвий цикл сторінки.

- На початку користувач виконує HTTP запит. Засоби для автоматичного його складання включають в себе всі сучасні браузери. Вони отримують інформацію про те куди треба перейти або з адресного рядка, або з допомогою механізму переходу за гіперпосиланням. У другому випадку також реферал у запиті (адреса сторінки, з якою прийшов користувач). Також браузер автоматично додає в тіло запиту кукі (пари ключ-значення). Для доменних імен першого порядку, які не відносяться до географічно прив'язаним, куки по всій області нижнього порядку імені адреси. Для інших (таких як ua, ru, uk) кукі єдині тільки в області повного доменного імені.

- Якщо користувач скористався доменним ім'ям, то його запит надходить на DNS (Domen Name System) сервер, який переглядає ім'я і або переходить за потрібного IP-адресою, або пересилає запит на інший DNS сервер для уточнення.

- Отримавши IP-адреса запит до сервера, який перехоплює його. Механізм перехоплення за допомогою портів, які сканує певний сервер. Один порт може контролюватися тільки одним сервером, але один сервер може контролювати кілька портів. У нашому випадку роль сервера виконує Apache.

- Apache переглядає розширення файлу, на який був здійснений запит. Якщо вказана тільки директорія він крок за кроком перевіряє кожен можливий варіант за замовчуванням (index.php, index.html, index.htm). Виставити цей список можна в налаштуваннях сервера, або у файлі .htaccess, якщо це дозволено в налаштуваннях веб-серверу.

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

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

- У випадку з *. php файлами він передає управління РНР.

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

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

- На цьому життєвий цикл сторінки закінчується.

Виходячи з цього розглянемо місця, де ми можемо зберігати інформацію між запитами:

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

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

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

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

3.2 Реалізація об'єктної моделі

Вся об'єктна модель програми ділитися на кілька частин:

­ абстрактні класи і інтерфейси для роботи з базою даних;

­ класи сутностей;

­ глобальні класи програми (для роботи з сесією і глобальними налаштуваннями програми);

­ класи для користувача сторінок;

­ класи сторінок, що використовуються в адміністративній частині;

­ обробники HTTP запитів, для асинхронної передачі даних екземпляру клієнтської сторінки.

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

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

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

Глобальні класи програми призначені для роботи з сесією, шаблонами, або іншими статичними елементами веб-системи.

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

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

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

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

4. ЗАБЕЗПЕЧЕННЯ БЕЗПЕКИ СИСТЕМИ

4.1 Захист облікового запису

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

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

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

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

4.2 Захист веб-серверу

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

Веб-сервер Apache підтримує 2 види аутентифікації:

Базова аутентификация (basic authentication) - ім'я й пароль передаються по мережі відкритим текстом.

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

5. АНАЛІЗ ДОСЛІДНОЇ ЕКСПЛУАТАЦІЇ

5.1 Загальні відомості

Програмний продукт був реалізований у середовищі Eclipse+PDT. Для керування даними була обрана СУБД MySQL 5.

В РНР реалізовані бібліотеки для роботи з MySQL сервером, що дозволяють працювати напряму з базою, надаючи вибір між звичайною та об'єктно-орієнтованою моделями. Окрім того дана СУБД є безкоштовною, як і РНР, та відрізняється високою продуктивністю.

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

Як інтерфейс доступу до бази даних був обраний MySQLi, що реалізує об'єктно-орієнтовану модель бібліотеки, для роботи з СУБД.

У якості веб-сервера був обраний Apache.

Apache (порт популярного unix-демону httpd на систему Windows) - зручний і продуктивний веб-сервер, що давно став стандартом де-факто для linux-серверів(як демон httpd), що має можливість підтримувати не лише протокол HTTP, але й HTTPS, а також має можливість легкого і швидкого підключення підтримки РНР.

За даними компанії Netcraft на квітень 2010, більше половини сайтів, розміщених у мережі Internet, обслуговуються веб-сервером Apache.

5.2 Установка системи

Для установки системи необхідно скопіювати всі файли додатка на комп'ютер, на якім розміщений веб-сервер, у директорію, на яку налаштовано Apache, це директива DocumentRoot у файлі httpd.config. Далі слід виконати наступні кроки, для остаточного налаштування сайту:

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

­ налаштувати базу даних, створити користувача, що має доступ до бази проекту;

­ внести зміни(логін та пароль користувача бази даних) до файлу config.php.

5.3 Тестування експлуатації системи

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

­ регресійне тестування;

­ функціональне тестування;

­ навантажувальне тестування.

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

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

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

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

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

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

Основним поняттям навантажувального тестування є "віртуальний користувач".

Управляючи числом віртуальних користувачів, тестувальник управляє навантаженням на систему. Віртуальний користувач виконує типові операції в системі шляхом відтворення трафіку, який відправляється клієнтським додатком на сервер. Іншими словами, віртуальний користувач виконує скрипти, які посилають на сервер пакети в форматі чинного протоколу, в нашому випадку це HTTP.

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

ВИСНОВКИ

У ході виконання курсової роботи була спроектована й розроблена веб-система обліку платних послуг вищого навчального закладу.

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

Проект був створений у середовищі розробки Eclips+PDT з використанням СУБД MySQL 5. У якості мови програмування використовувався PHP. Модель на стороні клієнта реалізована за допомогою Javascript з використанням фреймворка jquery.

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

У ході виконання економічної частини, було пораховано, що продукт “ Веб-система обліку платних послуг вищого навчального закладу” має очікуваний обсяг продаж 50 одиниць копій на ринку нового ПП, відпускна ціна за продаж однієї копії ПП складає 657,41 грн.

Сукупні витрати на розробку проекту - 13051,54 грн.

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

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

1. Старовойтова Т.Ф. Электронный бизнес и коммерция. [Текст] / Т.Ф. Старовойтова - М.: «И. Д. Вильямс», 2008. - 546 с.

2. Роберт Вийера. Программирование баз данных для профессионалов [Текст] / Роберт Вийера - М.: Диалетика, 2008. - 1072c.

3. Мартин Грабер. SQL. [Текст] / Мартин Грабер - К.: Издательство «ЛОРИ», 2003. - 644 с.

4. Дейт К. Дж. Введение в системы баз данных, 8-е изд. - [Текст] / Дейт К. Дж. - М.: «И. Д. Вильямс», 2005.-1328 с.

5. Эд Леки-Томпсон. PHP 5 для профессионалов [Текст] / Эд Леки-Томпсон, Хьяо Айде-Гудман, Алек Коув, Стивен Д. Новицки - СПб «Диалектика, Вильямс», 2006. - 608 с.

6. Яковлев А. А. Контекстная реклама. Основы, секреты, трюки. [Текст] / А.А. Яковлев - М.: Дилектика, 2007. - 401 с.

7. Киселев А.А. Электронная коммерция. Практическое руководство. [Текст] / А.А. Киселев - М.: ДиаСофтЮП, 2008. - 381 с.

8. Овчинников Р.Н. Интернет-маркетинг на 100 %. [Текст] / Р.Н. Овчинников - М.: Дилектика, 2009. - 240 с.

9. Шэри Тероу. Поисковая оптимизация сайтов. [Текст] / Шэри Тероу - М.: Символ, 2009. - 288 с.

10. Авинаш Кошик. Веб-аналитика: анализ информации о посетителях веб-сайтов. [Текст] / Авинаш Кошик - М.: Диалектика-Вильямс, 2008. - 464 с.

11. Тюриков А.Г. Интернет-реклама [Текст] / А.Г. Тюриков, Д.Е. Шляпин - М.: Дилектика, 2007. - 581 с.

12. Хьюз Миддлтон. Маркетинг на основе баз данных [Текст] / Хьюз Миддлтон - М.: Символ, 2008. - 448 с.

13. Дзензюк Б.В. Охорона праці. Збірник задач. [Текст] : учеб. / Б.В. Дзензюк, В.Г. Іванова - Харків: ХНУРЕ, 2006. - 244с.

14. Раздорожний А.А. Безопасность производственной деятельности: [Текст] : учеб. пособие / А.А. Раздорожний - М.: ИНФРА-М, 2003.- 208 с.

15. Сивко В.Й. Розрахунки з охорони працi. [Текст] : учеб. пособие / В.Й. Сивко - Житомир: ЖIТI, 2001. - 152 с.

ДОДАТКИ

Додаток А. Економічне обґрунтування проекту

А.1 Опис характеристик ПП і ринку збуту.

У ході виконання проекту була розроблена програмна система (ПП-програмний продукт) "Веб-система обліку платних послуг вищого навчального закладу" призначена для спрощення сплати послуг у ВНЗ.

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

Програмна система сплати за навчання у ВНЗ потребує наступні програмні засоби:

- Веб-сервер Apache(версії 1.3.х або вище);

- PHP 5.0 та вище;

- MySQL 5.1 та вище;

- місце на жорсткому диску - 490 Кб;

- інші особливі вимоги відсутні.

Використовувана мова програмування PHP.

Середовище розробки:

- Microsoft Windows XP Professional SP3;

- Apache 2.0.2 + PHP 5.3.1 + MySQL 5.0.40;

- Eclipse + PDT.

Дотримуються гарантії і захист споживчих якостей.

Таблиця А.1 - Розрахунок орієнтованої ємності ринку нового ПП

Галузь використання	Об'єм продажу, копій ПП
1. Вищі навчальні заклади 2. Середні навчальні заклади 3. Середні-професійні навчальні заклади	12 14 24
Разом	50

А.2 Розрахунок трудомісткості розробки ПП і заробітної плати виконавців.

Розрахунку одноразових витрат на розробку ПП передує оцінка трудомісткості та заробітної плати виконавців-розробніків нового ПП.

Середньоденна заробітна плата виконавця (З_сд) розраховується за формулою:

(А.1)

де - місячна заробітна плата виконавця, грн.;

- кількість робочих днів у місяці (n=22 дня).

У розробника архітектури середньоденна заробітна плата:

З_сд = 2970/22 = 135 грн

У програміста середньоденна заробітна плата:

З_сд = 5060/22 = 230 грн

У тестувальника середньоденна заробітна плата:

З_сд = 1760/22 = 80 грн

У менеджера середньоденна заробітна плата:

З_сд = 2420/22 = 110 грн

Таблиця А.2 - Розрахунок трудомісткості розробки ПП та заробітної плати виконавців

Вид роботи	Виконавець	Трудовитрати, чол.-день	Середньоденна заробітна плата, грн./чол.-день	Сума заробітної плати, грн.
	посада	кіль-кість
1	2	3	4	5	6
1. Розробка технічного завдання	Розробник архітектури	1	10	135	1350
2. Розробка бізнес-моделі	Розробник архітектури	1	3	135	405
3. Розробка схеми програм	програміст	1	2	230	460
4. Розробка програми	програміст	1	7	230	1610
5. Тестування програми	тестировщик	1	4	80	320
6. Оформлення документів	менеджер	1	2	110	220
7. Підготовка документації для користувачів	менеджер	1	2	110	220
Разом (ЗП)		8	32		4585

А.3 Розрахунок одноразових витрат на розробку ПП.

Розрахунок одноразових витрат на розробку ПП (інформаційного продукту, науково-технічної продукції) наведено в таблиці А.3.

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

Вартість машинного часу розраховується за формулою:

(А.2)

де - вартість однієї години роботи на ПЕОМ, грн.;

- сумарний час роботи на ПЕОМ; год.

= 10*8*32=2560

Відрахування до пенсійного фонду З_пф =0.332* З_ЗП

Відрахування на соціальне страхування на випадок безробіття З_сб =0.015* З_ЗП

Відрахування на соц. Страх. Від нещасних випадків і проф. Захворювань. З_сн=0.01* З_ЗП

Відрахування у фонд соціального страхування по тимчасовій непрацездатності З_нп=0.014*З_п

Вартість оплати послуг зв'язку, які надаються інтернет-провайдерами, операторами телефонного зв'язку при погодинній оплаті, розраховується за такими формулами:

(А.3)

В_зв = 5*15= 75 грн

де ? тариф (вартість) однієї години;

? кількість необхідних годин зв'язку;

Таблиця А.3 ? Розрахунок одноразових витрат на розробку ПП

№ з/п	Стаття витрат	Значення, грн.
1	2	3
1	Заробітна плата	4585
2	Витрати на соціальне страхування, у тому числі відрахування:
2.1	до пенсійного фонду	1522,22
2.2	до фонду соціального страхування по тимчасовій непрацездатності	64,19
2.3	до фонду соціального страхування на випадок безробіття	68,78
2.4	до фонду соціального страхування від нещасних випадків і професійних захворювань	45,85
3	Матеріальні витрати	300
4	Вартість машинного часу	2560
5	Інші витрати, у тому числі:
5.1	загальногосподарські витрати	1822
5.3	комунальний податок	8,50
5.4	вартість послуг зв'язку	75
6	Витрати на маркетингові заходи	2000
7	Разом (Врозр)	13051,54

А.4 Витрати на тиражування і відпускної ціни однієї копії.

Витрати на тиражування одного примірника З_т визначимо за такою формулою:

З_т = З'_мбп+ З'_ак+ З'_зп (грн) (А.4)

З'_мбп - витрати необхідні для тиражування (диск - 2 грн., коробка - 2 грн., етикетка - 2 грн., в сумі 6 грн.);

З'_зп - зарплата працівника, який тиражує (2 грн.);

З'_ак -витрати на оренду ПК на час тиражування однієї одиниці продукції (1грн.).

Зт = 6+2+1 = 9 грн.

Таблиця А.4 - Розрахунок витрат на тиражування та відпускної ціни однієї копії ПП

№ з/п	Стаття витрат	Значення, грн.
1	2	3
1	Розмір заробітної плати з нарахуваннями	2,74
2	Матеріальні витрати на тиражування однієї копії ПП	9
3	Оренда устаткування	100
4	Витрати на просування одиниці ПП	140
5	Витрати на адаптацію ПП до вимог споживача (%)	0
6	Витрати на тиражування однієї копії ПП	157,19
7	Витрати на розробку одиниці ПП	272,58
8	Собівартість однієї копії	429,77
9	Прибуток запланований	113,82
10	Розмір ПДВ	85,95
11	Відпускна ціна однієї копії ПП	657,41

А.5 Розрахунок витрат на просування ПП.

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

- реклама в Інтернеті;

- конференції з потенційними клієнтами.

Реклама в Інтернеті буде проводиться 1 року, останній рік тільки пів року. Буде вироблено 40 показів на день по 0,1 грн, на 3 сайтах. Тоді на місяць:

Р^'_і = 40*0,1*3*30 = 120 грн./місяць.