Інформаційне забезпечення процесів телекомунікаційного обміну

Остання версія Aptana Studio включає в себе сервер Jaxer, що дозволяє виконувати JavaScript на стороні сервера. А також інтегрована з сервісом Aptana Cloud, який пропонує легке розгортання та хостинг веб-додатків на серверах cloud computing компанії Aptana з можливістю миттєвої масштабованості ресурсів на вимогу. Даний хостинг підтримує наступні платформи: PHP 5, Jaxer, Ruby on Rails і Java, найближчим часом очікується підтримка веб-додатків на Python.

Aptana Studio включає до свого складу наступні JavaScript-бібліотеки і фреймворки (AJAX):

Adobe Spry;

jQuery

MochiKit;

Yahoo!UI Library;

MooTools;

Aflax;

Dojo;

Rico;

Prototype;

script.aculo.us;

Ext

Рисунок 2.9 - Зовнішній вигляд Aptana Studio



РОЗДІЛ 3. ПРОГРАМНА ЧАСТИНА

3.1 Вимоги до середовища функціонування

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

Основною мовою розробки виступав PHP 5.4, тому для успішного функціонування підсистема вимагає веб-сервер Аpache 2 або ж IIS 6.0 і вище.

Веб-сервер - це програмне забезпечення, яке обробляє веб-сторінки і пересилає їх браузеру користувача. Тому слід розділяти поняття сервер і веб-сервер. Так веб-сервер - це набір програмних рішень, а сервер - це апаратне забезпечення яке забезпечує роботу веб-серверу. Якщо в html коді інтернет сторінки є скрипти мови php та інших застосовуваних у мережі, які не обробляються браузером, їх обробляє веб-сервер. При цьому користувачеві відправляється сторінка з різними варіантами представлення. Роботу динамічних запитів пошуку так само виконує веб-сервер. Саме завдяки роботі веб-серверу інтернет користувачі можуть бачити динамічно оновлювані веб-сторінки, що відрізняються для різних облікових записів.

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

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

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

типи файлів, які необхідно кешувати або навпаки, не включати в кеш;

максимальний обсяг дискового простору, відведений під кеш;

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

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

Ядро Apache включає в себе основні функціональні можливості, такі як обробка конфігураційних файлів, протокол HTTP і система завантаження модулів. Ядро (в відміну від модулів) повністю розробляється Apache Software Foundation, без участі сторонніх програмістів.

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

Ядро Apache повністю написано на мові програмування C.

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

Другим за поширеністю веб-сервером є сервер IIS від компанії Microsoft. Даний web-сервер може працювати тільки в операційних системах Microsoft Windows. Тому всі серверні версії операційної системи Windows поставляються з інтегрованим IIS. Цей веб-сервер від Microsoft не має відкритого коду, що обмежує різноплановість настройки, якою відрізняється Apache.

Ранні версії IIS містили багато вразливостей, головна з яких була CA-2001-19, вона призводила до сумнозвісного Code Red черв'яка. 7.0 версія поки що не має задокументованих вразливостей. Хоча відкритий веб-сервер Apache має одну невиправлену вразливість, яка відтворюється тільки на MS Windows системах. В IIS 6.0 у Microsoft вирішили змінити поведінку попередньо встановлених ISAPI обробників, багато з яких призводили до вразливостей у версіях 4.0 та 5.0, таким чином зменшили поверхню атаки ISS. Також була додана функція «Web Service Extensions», яка запобігає запуску будь-яких програм без явного дозволу адміністратора. В IIS 7.0 компоненти розділені на модулі, таким чином встановлюються тільки необхідні компоненти, це також зменшує поверхню атаки. Ще одна функція додана для безпеки - це URLFiltering, з її допомогою відхиляються запити з підозрілих URL адрес, правила визначення підозрілих URL формуються користувачем.

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

Розроблений продукт буде успішно працювати як на apache2 так і на IIS 6.0, проте, краще всього використовувати сервер з встановленим Apache2.0.

Аpache 2 входить в базовий комплект Linux репозиторіїв і стабільніше за все працює саме на ядрі Linux.

Установка сервера вкрай проста навіть для звичайного користувача, для цього достатньо ввести в командному рядку з правами root наступне: # apt-get install apache2 (рис. 3.1).

Після чого система сама встановить всі залежності, необхідні файли і бібліотеки.



Рисунок 3.1 - Установка веб-серверу Apache

Після установки необхідно запустити веб-сервер командою apache2ctl start. (рис 3.2)

Рисунок 3.2 - Запуск веб-серверу

Та помістити файли сайту в папку /var/ WWW / (рис. 3.3).

Рисунок 3.3 - Дерево каталогів сайту

Далі необхідно сконфігурувати сенсори.

Конфігурувати необхідно кожен сенсор в кожній директорії вручну, система не має ні локальних ні зовнішніх файлів конфігурації через уразливість в include («script.php»), яка дозволяє зловмисникові підключити на виконання довільний код з будь-якого серверу.

Для конфігурації сенсора відкриваємо його будь-яким текстовим редактором,

Переходимо до 160 рядку і міняємо електронну адресу на ту, куди повинні надходити повідомлення про атаку, а також копія логів (рис. 3.4).

Рисунок 3.4 - Конфігурація сенсору

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

Для цього необхідно змінити рядок з SRC = www.def.ru/index.php на

адресу необхідної веб-системи (рис. 3.5).

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



Рисунок 3.5 - Конфігурація index.php

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

Розглянемо відображення атаки на прикладі SQL-ін'єкція атаки націленої на скрипт взаємодіє з СУБД MySQL, а саме administrator.php.

Зловмисник заходить на сайт. Вводить запит, який дозволить дізнатися чи існує така вразливість, наступним чином:

www.domain.com/administrator.php? SELECT * FROM'USERS'Where=1

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

Рисунок 3.6 - Повідомлення про блокіровку



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

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

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

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

Атакуючий побачить замість контенту, що повинен видаватися користувачам, повідомлення про блокування доступу до ресурсу (рис. 3.7).

Рисунок 3.7 - Повідомлення про блокування

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

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

1. «Проксі». Містить в собі кінцеву IP-адресу після проходження трафіку через всі маршрути. Таким чином в цьому полі міститься адреса кінцевого маршрутизатора. Найчастіше, якщо не був використаний анонімний проксі-сервер, тут буде міститися мережева адреса шлюзу провайдера.

2. «Запит» містить в собі стан рядка браузера зловмисника на момент атаки. По ньому можливо дізнатися про вектор атаки, мету атаки, а також який скрипт-сенсор атакувався.

3. «Запит на отримання сторінки» містить в собі запит до скрипта. Таким чином, якщо «Запит» і «Запит на отримання стрніки» не збігаються - є ймовірність того, що спроба атаки була проведена за допомогою відправки модифікованих заголовків HTTP-пакетів.

4. «Локальна адреса» може містити в собі локальний IP-адрес внутрішньої мережі провайдера послуг Інтернету атакуючого.Цей пункт потрібен для полегшення завдання при розслідуванні інциденту. Знаючи IP-адресу провайдера, а також локальну адресу атакуючого, можна отримати дані про фізичну місце проживання, або про місце, за яким зафіксовано таку адресу, що безсумнівно полегшить процес пошуку зловмисника.

5. «Шлюз до проксі» може містити в собі адресу останнього маршрутизатора до проксі-сервера, якщо проксі сервер підтримує трансфер-трафік. Атаких в загальному доступі переважна більшість.

6. «Версія браузера або ПЗ» містить інформацію про ПЗ, яке було використано на момент атаки. Багато сканерів вразливостей можна визначити за такими логами. Припустимо сканер вразливостей VEGA при аналізі буде виглядати як Vega/1.21 (X11; Linux i386). Це поле містить в собі і відомості про операційну систему атакуючого, графічне оточення, а також бібліотеку, яка використовується для взаємодії мережевого ПЗ з веб-сервером.

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

8. «Мовні налаштування» містить в собі бажані користувачем мови. При зіставленні розташування проксі і шлюзу з мовою можливо з більшою ймовірністю припустити реальне розташування зловмисника. За статистикою російського ресурсу www.securitylab.ruбільше 60% зловмисників вкрай мало надають значення таким дрібницям.

9. «Санкція сесії» містить в собі дані про аутентифікаціюкористувача. Тобто, якщо атакуючий провів атаку будучи під своїм обліковим записом - це поле буде містити дані про цей запис.

10. «Cookie-маркер» містить в собі мітку зловмисника. Дозволяє дізнатися чи був атакуючий викритий в атаці раніше. Такі дані актуальні у тому випадку, уоли атакуючий змінив провайдера, місто виходу в Інтернет абовикористав новий анонімний проксі-сервер.

11.«Віддалений клієнтський порт» дозволяє дізнатися порт, який був використаний додатком для відправки пакетів на сервер. Нештатним стандартом у розробників браузерів є використання портів 49000-54000. Якщо порт перевищує це значення, є ймовірність того, що запити були надіслані зовсім не з браузеру.

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

13. «Протокол» дозволяє дізнатися яку саме версію HTTP-протоколу використовував атакуючий для проведення того чи іншого виду атаки.

14. «Стан з'єднання» містить інформацію про з'єднання клієнта і сервера. Приймає два значення - close и keep-alive. Перше позначає, що з'єднання успішно обірване, друге, що з'єднання з клієнтом сервер не розірвав.

15. «Заголовок HOST» иістить в собі значення параметра HOST з заголовка HTTP-пакета. Це дозволяє також визначити вектор атаки. Для атаки, метою якої є відмова в обслуговуванні, необхідно в тілі пакету, в параметрі HOST, задати IP-адресу сервера, а не його доменне ім'я.

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

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

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

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

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

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

Рисунок 3.8 - Зовнішній вигляд звіту

Що б перезавантажити веб-сервер достатньо ввести з клавіатури apache2ctl restart.

Що б відключити веб сервер достатньо ввести команду apache2ctstop (рис.3.9).

Nfrj; командний рядок дозволяє виконати абсолютно будь-якbq не графічний додаток на сервері.



Рисунок 3.9 - Перезавантаження серверу

Завдяки використанню бібліотеки evercookie.js обхід підсистеми захисту стає практично не здійсненним завданням.

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

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

HTTP Cookies;

Local Shared Objects (Flash);

збереження Cookies в значеннях RGB;

збереження Cookies в Web History;

HTML5 Session Storage;

HTML5 Local Storage;

HTML5 Global Storage;

HTML5 Database Storage через SQLite.

Далі необхідно вкласти в кожен сенсор наступний код:

<script type="text/javascript" src="evercookie.js"></script>

<script> var ec = new evercookie(); ec.set(",Banned", "24"); // ec.get("id", function(value) { alert("Banned " + 24) }); // </script>

Таким чином сенсор віддає Cookies-маркери з восьми різних місць, що гарантує практично повну впевненість в тому, що заблокований в минулому зловмисник, змінивши браузер і місце доступу, все рівно буде опізнаний підсистемою захисту і доступу до системи навчання не отримає. Передача маркерів здійснюється наступним чином. Наприклад, для доступу до сторінки www.example.org/index.html браузер відправляє на сервер www.example.org наступний запит: GET /index.html HTTP/1.1

Host: www.example.org Сервер відповідає, відправляючи запитувану сторінку разом з текстом, що містить HTTP-відповідь. Там буде міститися вказівка браузеру зберегти Cookies:

HTTP/1.1 200 OK

Content-type: text/html

Set-Cookie: name=value

Якщо є рядок Set-Cookie, браузер запам'ятовує рядок name = value (ім'я = значення) і відправляє його назад серверу з кожним наступним запитом:

GET / HTTP/1.1 spec.html

HOST: www.example.org

Cookie: name = value

Accept: * / *



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

В той момент коли зловмисникові встановлюються Cookie-маркери, створюється. PNG зображення в якому всі значення RGB кольоів виставляються відповідно до даних про сесії. Такий PNG малюнок відправляється браузеру з позначкою на зберігання 20 років.

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

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

Не варто забувати також і про локальні загальні об'єкти - це сховище Flash-скриптів, Flash-відеороликів.

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

Відразу варто виділити те, що такий вид маркування не прив'язаний до браузеру.

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

Flash-Cookie дозволяють зберігати набагато більший обсяг даних (як правило, 100 Кб), що збільшує кількість налаштувань користувача, доступних для збереження.

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

function getCookie(best_candidate, all_candidates)

{

for (var item in all_candidates) document.write("Storage mechanism " + item + " returned: " + all_candidates[item] + "<br>");

}

ec.get("id", getCookie);

</script>



РОЗДІЛ 4. ЕКОНОМІЧНА ЧАСТИНА

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

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

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

4.1 Організаційно-економічне обґрунтування проекту

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

У ТЕО необхідно розглянути наступні питання:

планування розробки із побудуванням сітьового графіку;

розрахунок вартості розробки;

економічна ефективність розробки;

склад і призначення основних розділів господарського договору.

У організаційній частині ТЕО необхідно розрахувати термін розробки і побудувати сітьовий графік робіт із створення програмного забезпечення.

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

4.2 Організаційне обґрунтування проекту

4.2.1 Класифікаційна оцінка різновиду проекту

клас проекту - монопроект (проект, що виконується в рамках однієї організації та направлено на створення конкретної технології);

тип проекту - технічний (проект направлено на отримання технічних знань та навиків);

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

тривалість - короткостроковий (строк виконання проекту до 3 років);

складність - простий (проект не є організаційно та технічно складним, не потребує великих ресурсів);

розмірність - мілкий (невеликий по масштабу, простий і обмежений об'ємами, допускає ряд спрощень при проектуванні та реалізації);

рівень - галузевий (створення проекту направлено на розвиток галузі інформаційних технологій).

4.2.2 Визначення мети та результатів проекту

Мета роботи - підсистема захисту даних.

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

Етапи та строки виконання проекту:

визначення цілей та задач проектування програмного продукту (орієнтовний термін виконання - 5 днів);

аналіз вимог, які пред'являються до системи, що проектується (орієнтовний термін виконання - 3 дні);

збір інформації, матеріалу (орієнтовний термін виконання - 7 днів);

аналіз аналогічних систем (орієнтовний термін виконання - 5 днів);

вибір засобів і методів створення ПП (орієнтовний термін виконання - 4 дні);

техніко-економічне обґрунтовування (орієнтований строк виконання - 8 днів);

розробка архітектури проекту (орієнтовний термін виконання - 8 днів);

фіктивна робота (орієнтовний термін виконання - 0 днів);

розробка алгоритмів проектування ПП (орієнтовний термін виконання - 6 днів);

програмування і коректування програми (орієнтовний термін виконання - 22 дні);

створення інтерфейсу (орієнтовний термін виконання - 7 днів);

тестування і відладка проекту (орієнтовний термін виконання - 15 днів);

підтвердження закінчення робіт (орієнтовний термін виконання - 6 днів);

підготовка проекту до експлуатації (орієнтовний термін виконання - 6 днів);

підготовка документів і здача проекту замовникові (орієнтовний термін виконання - 5 днів);

оцінка результатів проекту й підведення підсумків (орієнтовний термін виконання - 3 дні);

У кваліфікаційному проекті буде представлений наступний склад робіт:

технічне завдання (термін виконання - 15 днів);

розробка ескізного проекту (термін виконання - 17 днів);

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

розробка робочого проекту (термін виконання - 36 днів);

впровадження проекту (термін виконання - 9 днів).



4.2.3 Визначення навколишнього середовища і учасників проекту

Навколишнє середовище проекту - сукупність зовнішніх і внутрішніх чинників, які роблять вплив і дію на проект:

зовнішні чинники:

економічні (на проект можуть вплинути рівень цін, стан ринку збуту, стан ринку інвестицій у разі потреби розвивати проект за допомогою інвестиційних вкладень);

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

внутрішні чинники

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

Визначити учасників проекту можна таким чином:

Замовник (головний учасник - майбутній власник і користувач результатів проекту - ОДАХ, кафедра ІТ).

Керівник проекту (керівник диплому, Котенко К.В.).

Команда проекту - специфічна організаційна структура, створювана на період здійснення проекту (виконавці - керівник проекту, програміст-розробник Сівак О.П.)

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

4.2.4 Побудова схем, пов'язаних з виконанням проекту

Сітьова модель з розрахунком параметрів. В таблиці 4.1 представлено склад робіт та їх тривалість.



Таблиця 4.1 - Склад робіт проекту

№ код роботи	Назва роботи	Т (дні)	№ код попередньої роботи
1	2	3	4
0-1	Визначення цілей та задач проектування програмного продукту.	5	-
1-2	Аналіз вимог, які пред'являються до системи, що проектується.	3	0-1
2-3	Збір інформації, матеріалу.	7	1-2
2-4	Аналіз аналогічних систем.	5	1-2
3-5	Вибір засобів і методів створення ПП.	4	2-3
4-6	Техніко - економічне обґрунтовування.	8	2-4
5-7	Розробка архітектури проекту.	8	3-5
6-7	Фіктивна робота	0	4-6
7-8	Розробка алгоритмів проектування ПП.	6	5-7, 6-7
8-9	Програмування і коректування програми.	22	7-8
7-9	Створення інтерфейсу.	7	5-7, 6-7
9-10	Тестування і відладка проекту.	15	7-9, 8-9
10-11	Підтвердження закінчення робіт.	6	9-10
10-12	Підготовка проекту до експлуатації.	6	9-10
11-12	Підготовка документів і здача проекту замовникові.	5	10-11
12-13	Оцінка результатів проекту й підведення підсумків.	3	10-12, 11-12

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

Розрахунок параметрів сітьового графіку:

ранній початок роботи, Тiр;

раннє закінчення роботи, Тiр;

пізніший початок роботи, Тiп;

пізніше закінчення роботи, Тjп;

резерв часу події, Rj;

Lкр - тривалість критичного шляху.



Рисунок 4.1 - Сітьовий графік з виділеним критичним шляхом

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

В даному сітьовому графіку критичний шлях (що відмічений жирними стрілками) проходить крізь вершини: 0-1-2-3-5-7-8-9-10-11-12-13 і має довжину Tкр = 84 дні.

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

Тривалість критичного путі (84 дні) не перевищує тривалість розробки проекту (що складає 110 днів). Отже, оптимізувати сітьову модель немає необхідності.

Таблиця 4.2 - Розрахунок параметрів сітьової моделі

Роботи	Ранній строк здійснення події і, Тір	Тривалість роботи, Тij	Ранній строк здійснення події j, Тjр	Пізній строк здійснення події i, Тіп	Тривалість роботи, Tij	Пізній строк здійснення події j, Tjп	Повний резерв, Rj
i	j
1	2	3	4	5	6	7	8	9
0	1	0	5	5	0	5	5	0
1	2	5	3	8	5	3	8	0
2	3	8	7	15	8	7	15	0
2	4	8	5	13	14	5	19	6
3	5	15	4	19	15	4	19	0
4	6	13	8	21	19	8	27	6
5	7	19	8	27	19	8	27	0
6	7	21	0	21	27	0	27	6
7	8	27	6	33	27	6	33	0
8	9	33	22	55	33	22	55	0
7	9	27	7	34	48	7	55	21
9	10	55	15	70	55	15	70	0
10	11	70	6	76	70	6	76	0
10	12	70	6	76	75	6	81	5
11	12	76	5	81	76	5	81	0
12	13	81	3	84	81	3	84	0
13	-	84	-	-	84	-	-

4.3 Маркетингове обґрунтування проекту

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

4.3.1 Оцінка ринку збуту й конкуренція

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

Регіон і ринок збуту - ринок інформаційних технологій та послуг.

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

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

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

інтелектуалізація існуючих проектів;

оптимізація пошуку інформації;

зменшення часу обробки існуючої інформації;

4.3.2 Стратегія розвитку проекту

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

Формування опитування:

повідомити потенційного покупця про існування товару;

проінформувати його про функціональні можливості системи;

надати докази щодо задовільної якості;

надати гарантію якості і роботи програмного продукту;

переконати, що товар краще, економічно вигідніше, ніж інші.

Размещено на Allbest.ru