3. Реалізація проекту
3.1. Загальна схема проекту
Виходячи з вимог до функціональності системи, вона має бути побудованою за клієнт-серверною технологією. З цього випливає, що на стороні клієнта і на стороні сервера повинні працювати окремі компоненти, з різною функціональністю. На даному етапі проектування вже можна виділити на ступні:
3.1.1. Компонент зберігання інформації (глобально)
Реалізація:
База даних
Розташування:
сервер бази даних (DataBase Server).
Функції:
зберігання інформації
захист даних на рівні сервера бази даних
частина логіки системи (рівень бази даних).
Доступ:
адміністратори бази даних - необмежений,
адміністратори системи – читання та запис (обмежений),
користувачі – читання та запис (обмежений)
Взаємодія:
Компонент взаємодії серверної частини з базою даних
Компонент взаємодії клієнтської частини за базою даних
3.1.2. Компонент взаємодії адміністративної частини з базою даних
Реалізація:
Веб-сервіс
Розташування:
сервер додатків (Application Server)
Функції:
додатковий захисний рівень даних від несанкціонованого доступу
окремий рівень абстракції для гнучкості системи у випадках змін функціональності
авторизація користувачів системи
Прямий доступ до бази даних (читання, запис)
Доступ:
всі користувачі (функція авторизації),
адміністратори системи (усі функції, після вдалої авторизації)
користувачі системи (деякі функції, після вдалої авторизації)
Взаємодія:
Компонент зберігання інформації
Адміністративна частина
3.1.3. Адміністративна частина
Реалізація:
WEB-сайт
Розташування:
сервер додатків (Application Server).
Функції:
Відображення інформації
Створення опитувань
Керування опитуваннями
Керування користувачами
Редагування довідкової інформації
Моніторинг процесу роботи
Доступ:
Адміністратори системи (повна функціональність)
Зареєстровані користувачі системи (обмежена функціональність)
Взаємодія:
Компонент взаємодії адміністративної частини з базою даних
3.1.4. Компонент зберігання інформації (локально)
Реалізація:
Файл з розширенням .mdf
Розташування:
Файлова система мобільного пристрою
Функції:
Збереження даних локально (без відправки на сервер)
Відтворення структури глобального сховища локально
Взаємодія:
Клієнтська частина
3.1.5. Компонент взаємодії клієнтської частини з базою даних
Реалізація:
WEB-сервіс
Розташування:
сервер додатків (Application Server).
Функції:
Взаємодія з сервером бази даних (читання, запис)
Взаємодія з локальним сховищем клієнтської частини (читання, запис)
Синхронізація даних між глобальним та локальним сховищами
Доступ:
Зареєстровані користувачі системи
Взаємодія:
Сервер бази даних (глобальне сховище)
Клієнтська частина (локальне сховище)
3.1.6. Клієнтська частина
Реалізація:
Програма Windows Mobile
Розташування:
Мобільний пристрій (файлова система)
Функції:
Отримання інформації безпосередньо від джерела
Первинна обробка отриманих даних
Підготовка даних до занесення у сховище (форматування)
Збереження даних локально
Автономна робота (без прив’язки до місця)
Синхронізація з сервером бази даних (в обидві сторони)
Доступ:
Зареєстровані користувачі системи
Взаємодія:
Компонент взаємодії клієнтської частини з базою даних
Компонент зберігання інформації (локально)
Таким чином, можна виділити три концептуальні рівні проекту:
Інтерфейс користувача (WEB-сайт, програма Windows Mobile)
Сервіси
База даних
Графічне представлення схеми проекту наведене в рис. 5
Рисунок 5. Загальна схема проекту
3.2. Сценарій роботи системи
Перед тим, як починати проектування бази даних і розробку компонентів проекту, необхідно описати поведінку кожної з частин системи. Мається на увазі, що кожен з компонентів повинен виконувати чітко ті функції, що відносяться до його сфери впливу. Можна роздивлятись їх як деякі сутності, що отримують деякі команди або дані на вхід, обробляють їх певним чином і видають на вихід ту інформацію, яка відповідає очікуванням. Також важливо визначити, в якій послідовності компоненти взаємодіють одне з одним, і в результаті виклику яких функцій. Крім того, щоб підготувати ґрунт для етапу проектування бази даних, необхідно дати визначення основним поняттям, що фігурують в системі на концептуальному рівні і визначити їх властивості.
В даному випадку не існує чіткої точки входу в роботу системи. Причина в тому, що є дві окремі частини – серверна та клієнтська, які, з точки зору загального сценарію, працюють незалежно одна від одної. Але, якщо брати конкретний випадок початку роботи «з чистого аркуша», то починається все з серверної частини, а точніше, з конструктору опитувань.
Конструктор опитувань
Основною логічною одиницею системи можна назвати «Опитування». Саме навкруги нього і відбувається вся подальша робота. Опитування може мати свою дату активізації і закінчення. Також, якщо опитування активне, то потрібно слідкувати за тим, щоб його хтось проводив в період його дії. Опитування може бути створене ще до того, як набере чинності. Тобто, воно в стані, який можна назвати «заплановане». Після того, як наступає дата активації опитування, воно переходить в стан «активне», і після дати закриття опитування стає «закритим».
Кожне опитування має перелік питань. «Питання» - це вже окрема сутність з окремими властивостями. По-перше потрібно визначити, які типи питань будуть використовуватись в даній системі, для того, щоб можна було спроектувати процес опитування максимально зручним способом. Умовно, їх можна поділити на відкриті, закриті та змішані. Відкриті – це ті, що передбачають будь-яку відповідь, що спаде на думку опитуваному. Закриті питання мають декілька варіантів відповідей і опитуваний повинен вибрати один (або декілька) з них. Змішані – дещо середнє між відкритими та закритими. Таким чином, можна сказати, що одна з властивостей поняття «Питання» - тип. Вона допоможе програмно визначити інтерфейс клієнтського додатку для кожного конкретного питання. По-друге питання можуть бути обов’язковими для відповіді, або ні. І наостанок, потрібно знати, чи може опитуваний вибрати декілька варіантів відповідей, чи потрібно вибрати тільки одну.
В залежності від того, відкрите питання, чи закрите, воно може мати один, або декілька варіантів відповідей. «Відповідь» - поняття, що закінчує ланцюг «Опитування» - «Питання» -«Відповідь». Якщо питання, до якого належить відповідь (відповіді) було відкритим – то варіантів відповідей просто не буде. Опитуваний сам створює свій варіант. Якщо питання було закритого типу – воно повинно мати два або більше варіантів відповідей.
Виходячи з вищеописаної інформації, можна вивести алгоритм роботи конструктору опитувань: спочатку створюється опитування, задаються обов’язкові властивості (такі, як дата активації, закінчення та перелік користувачів, які будуть проводити дане опитування. Потім в готове опитування додаються питання. Після цього в кожне питання додаються варіанти відповідей. Ця структура повинна зберігатись в базі даних для того, щоб клієнтська програма могла правильно відображати опитування.
Клієнтська програма
Робота повинна починатись з авторизації. Якщо вона проходить успішно, потрібно синхронізувати клієнтське сховище з сервером і отримати оновлену інформацію. Коли користувач входить в систему, відбувається запит на сервер, який вертає тільки ті опитування, на яких адміністратор позначив саме цього користувача. Користувач (опитувач) вибирає опитування і бачить на екрані запит на введення даних опитуваного (вік, стать, тощо), що потрібні для статистики та формування окремих груп за певними ознаками. Після підтвердження цих даних, опитувач бачить на екрані перелік питань вибраного опитування з варіантами відповідей. Після успішного завершення опитування користувач зберігає результати в локальному сховищі. Також, потрібно надати можливість перервати опитування в будь-який момент. Після того, як проходить певний проміжок часу, або збирається певна кількість інформації (оговорюється в індивідуальному режимі), користувач повинен синхронізувати локальне сховище даних з базою даних на сервері. Після цього адміністратор може переглядати хід опитувань та бачити статистику по результатах.
Монітор опитувань
Цей компонент можна розділити на декілька більш дрібних за функціональним призначенням.
Перегляд опитувань
Призначення - відображення переліку існуючих опитувань. Також, тут потрібен фільтр опитувань за станом, тобто адміністратор повинен мати змогу передивлятись опитування певного стану (заплановані, активні, закриті). Це потрібно для окремих задач адміністратора. Опитування мають відображатись в скороченому вигляді (адміністратор має бачити тільки ті дані, що необхідні для того, щоб вибрати конкретне опитування за певними ознаками і перейти до його детального перегляду. Це, в першу чергу, стан опитування, дата активації, дата закінчення. Також, потрібно бачити, скільки респондентів було опитано, щоб орієнтуватись, чи назначати на це опитування додатково людей, чи це не потрібно.
Перегляд деталей опитування
Призначення – надання повної інформації про вибране опитування. Адміністратор може перейти до перегляду деталей опитування, вибравши його зі списку. В цьому представленні потрібно відобразити наступні дані, що стосуються безпосередньо самого опитування:
Назва опитування
Стан
Дата створення
Дата активації
Дата закінчення
Термін дії
Інтерв’юери, що беруть (брали або будуть брати) участь в опитуванні
Кількість опитаних респондентів
Крім того, необхідно показати деякі дані, щодо результатів проведення вибраного опитування, тобто по кожному з варіантів відповідей кожного з питань потрібно вказати, скільки людей вибрали цю відповідь, а також розбити людей на групи по заданим параметрам (вік, стать, тощо).
Також, окремо має бути доступна особиста інформація опитаних респондентів та детальна інформація по відповідям в рамках окремого опитування.
Перегляд інтерв’юерів
Призначення – відображення інтерв’юерів, існуючих в системі на даний момент. Потрібно надати наступну інформацію:
П.І.Б.
Вік
Стать
Опитування, що були проведені інтерв’юером (кількість опитаних по кожному)
Опитування, що проводяться інтерв’юером на даний момент (кількість опитаних по кожному)
3.3. Проектування бази даних
Система повинна зберігати певну кількість даних певний час. Крім того, дані повинні бути захищені та мати певну структуру, зручну для доступу до потрібної інформації. Було вирішено використовувати базу даних для збереження інформації. Потрібно усвідомлювати, що від того, як буде спроектована структура бази даних, буде залежати і подальша робота за нею (швидкість, зручність, безпека).
Проектування бази даних буде проходити в 3 етапи:
Концептуальний рівень
Сутності
Атрибути
Зв’язки
Логічний рівень
Записи
Елементи даних
Зв’язки між записами
Фізичний рівень
Групування даних
Індекси
Методи доступу
Концептуальне проектування – збір, аналіз та редагування вимог до даних. Для цього здійснюються наступні дії:
Дослідження предметної області, вивчення її інформаційної структури
Виявлення усіх фрагментів, кожний з яких характеризується користувацьким представленням, інформаційними об’єктами та зв’язками між ними, процесами над інформаційними об’єктами
Моделювання та інтеграція всіх представлень
Логічне проектування – перетворення вимог до даних в структури даних. На виході отримуємо СКБД-орієнтовану структуру бази даних і специфікації прикладних додатків. На цьому етапі іноді моделюють бази даних, застосовуючи до різних СКБД та проводять порівняльний аналіз моделей.
Фізичне проектування – визначення особливостей зберігання даних, методів доступу до даних, тощо.
3.3.1. Концептуальний рівень
Основою всієї інформаційної частини системи є опитування. Тож, в першу чергу, можна виділити цю сутність, а вже потім усі інші. Нижче наведений перелік сутностей системи та їх атрибутів:
Опитування
Найменування
Дата створення
Дата активації
Дата закінчення
Стан
Ким створений
Пов’язана із сутностями «Стан опитування» (один-до-багатьох), «Користувачі системи» (один-до-багатьох)
Питання
Питання (текст)
Чи обов’язкове
Декілька варіантів відповідей
Тип (закрите/відкрите)
Пов’язана із сутностями «Опитування» (один-до-багатьох), «Тип питання» (один-до-багатьох)
Варіант відповіді
Варіант відповіді (текст)
Пов’язана із сутністю «Питання» (один-до-багатьох)
Користувач системи
Ім’я
Прізвище
По-батькові
Стать
Дата народження
Група користувачів
Пов’язана із сутністю «Групи користувачів» (один-до-багатьох)
Респондент
Ім’я
Вік
Стать
Сфера діяльності
Додаткова інформація
Пов’язана із сутністю «Варіанти відповідей» (багато-до-багатьох)
Сфери діяльності
Назва
Пов’язана із сутністю «Респондент» (один-до-багатьох)
Стан опитування
Назва
Пов’язана із сутністю «Опитування» (один-до-багатьох)
Група користувачів
Назва
Пов’язана із сутністю «Користувачі» (один-до-багатьох)
Тип питання
Назва
Пов’язана із сутністю «Питання» (один-до-багатьох)
3.3.2. Логічний рівень
Логічне представлення бази даних відображене на рисунку 6.
Рисунок 6. Структура бази даних
3.3.3. Фізичний рівень
Цілісність даних
Забезпечення цілісності даних є важливою задачею при проектуванні й експлуатації систем обробки даних (СОД).
Проблема цілісності полягає в забезпеченні правильності даних у базі даних у будь-який момент часу. Цілісність - актуальність і несуперечність інформації, її захищеність від руйнування й несанкціонованої зміни.
Цілісність є одним з аспектів інформаційної безпеки наряду з доступністю – можливістю із прийнятними витратами отримати необхідну інформаційну послугу, і конфіденційністю – захистом від несанкціонованого доступу.
Цілісність даних описується набором спеціальних дій, що називаються обмеженнями цілісності. Обмеження цілісності являють собою твердження про припустимі значення окремих інформаційних одиниць і зв'язках між ними. Ці обмеження визначаються в більшості випадків особливостями предметної області, хоча можуть відбивати й чисто інформаційні (лінгвістичні) характеристики. Наприклад, якщо використовуються цифрові коди для позначення якої-небудь номенклатури, то обмеження на тип використовуваних символів для відповідного атрибута в БД визначаються не специфікою предметної області, а просто обраним способом кодування, обмеження, що виражається в тому, що вік працюючого повинен бути не менший 16 років, - трудовим законодавством, тобто тільки специфікою предметної області.
При виконанні операцій над БД перевіряється виконання обмежень цілісності. Дії, що приводять до порушення подібних обмежень, відкидаються. Обмеження цілісності можуть застосовуватись до різних інформаційних об’єктів: таблицям, файлам, полям, записам, тощо.
Проблема забезпечення цілісності по зв'язку (і по існуванню) по-різному виглядає при додаванні нового запису у пов’язану таблицю, при коректуванні записів, при видаленні пов’язаних записів. Наприклад, якщо видаляється запис із основної таблиці, то можливі наступні варіанти:
Запис в основній таблиці можна видаляти тільки в тому випадку, якщо немає пов'язаних з нею записів у підлеглій таблиці;
При видаленні запису основної таблиці видаляються всі пов'язані з нею записи в залежній таблиці (так зване каскадне видалення);
Якщо це просте обмеження по зв'язку, а не обмеження по існуванню, то можливий варіант, коли при видаленні запису основної таблиці значення відповідного поля пов'язаних з нею записів повинні бути замінені на "порожньо".
Видалення записів залежної таблиці не може привести до порушення обмеження цілісності по зв'язку або існуванню.
В даному проекті цілісність бази даних буде реалізовано за допомогою первинних та зовнішніх ключів, збережених процедур, користувацьких функцій та тригерів.
3.4. Реалізація функціональності системи
3.4.1. Визначення функціональних пріоритетів
Весь проект можна розглядати як набір сценаріїв поведінки компонентів системи. Відповідно до вибраної методології розробки, по завершенні кожної ітерації програмний продукт повинен бути в робочому стані. Тому в першій ітерації розробки потрібно реалізувати тільки той функціональній набір, що дозволить побачити проект в робочому стані, надасть можливість оцінити швидкість доступу до даних та зручність інтерфейсу користувача, щоб мати змогу без особливих затрат зусиль та робочого часу, змінити елементи, що цього потребують, в наступних ітераціях.
В силу архітектури системи, для коректної роботи потрібні усі компоненти, але для першого етапу розробки не потрібно реалізовувати весь функціонал кожного з них. Нижче наведено перелік компонентів та функціональність, що необхідно реалізувати в першу чергу.
База даних
База даних необхідна для зберігання даних. Усі дані, з якими працюватимуть і користувачі клієнтської частини і користувачі серверної – знаходяться в базі даних. Без існуючої бази даних просто неможливо створювати інші компоненти системи, тому що не буде можливості перевірити функціональні можливості цього компонента. Тому в першу чергу, потрібно створити вже спроектовану базу даних і додати в неї весь набір необхідних для першої ітерації збережених процедур та користувацьких функцій:
Додавання користувача в базу даних
Додавання респондента в базу даних
Створення опитувань (питань, варіантів відповідей)
Отримання даних користувача
Отримання існуючих опитувань (і їх питань, варіантів відповідей)
Веб-сервіс
Веб-сервіс потрібний для того, щоб отримувати та передавати дані від інтерфейсу користувача в базу даних. Це шар між користувачем і базою даних, який забезпечує надання більш високого (і тому зручного) рівня абстракції представлення даних. Клієнтський інтерфейс адміністративної частини не може напряму звертатися до бази даних, тому що це являється неприпустимою помилкою проектування системи в плані безпеки даних. Цей компонент майже повністю відтворює функціональність бази даних, але він працює з вже типізованими даними, що мають певний формат, і тому надає можливість працювати з ними вже безпосередньо в інтерфейсі користувача. Крім того, саме веб-сервіс відповідає за «правильність» введеної або отриманої інформації, що забезпечує цілісність даних. Перелік функцій, що повинен реалізувати веб-сервіс в першій ітерації:
Додавання користувача в базу даних
Додавання респондента в базу даних
Створення опитувань (питань, варіантів відповідей)
Отримання даних користувача
Отримання існуючих опитувань (і їх питань, варіантів відповідей)
Перевірка даних на «правильність»
Створення «обгортки» бази даних в форматі, зрозумілому рівню інтерфейсу
Веб-сайт
Веб-сайт потрібен для безпосередньої взаємодії з користувачем системи. Він має відображати дані, що повертає сервіс з бази даних та передавати дані, введені користувачем, веб-сервісу на обробку. Цей компонент - передостанній рівень в ланцюгу роботи серверної частини системи. Останній – користувач. Необхідна функціональність:
Створення користувачів (адміністраторів, респондентів)
Створення опитувань (питань, варіантів відповідей), визначення їх параметрів
Отримання даних користувача
Отримання інформації про існуючі опитування (їх питання, варіанти відповідей)
Отримання статистичної інформації по існуючим опитуванням (скільки людей опитано, процентне співвідношення варіантів відповідей, тощо)
Співставлення
Сервіс синхронізації
Сервіс синхронізації виконує проміжну роль між базою даних та клієнтською програмою мобільного пристрою. Основна його задача – за вимогою користувача звернутися до бази даних, отримати дані і порівняти їх з тими даними, що зберігаються безпосередньо на мобільному пристрої. Якщо є відмінності – синхронізувати обидва сховища даних таким чином, щоб вони містили однаковий набір даних. Немає сенсу реалізовувати цей компонент частково, тому що різниця тільки в тому, яку кількість таблиць він має синхронізовувати. Так як алгоритм синхронізації для всіх таблиць однаковий, доцільно реалізувати синхронізацію для всієї бази даних одразу, таким чином надаючи можливість більше не повертатись до цієї складової.
Клієнтська програма
Задача клієнтського програмного забезпечення на мобільному пристрої – надати можливість інтерв’юеру проводити опитування серед населення без постійного доступу до бази даних (автономний режим) і прив’язаності до конкретного місця (мобільність). До першочергових функцій програми входять наступні:
Авторизація користувача (інтерв’юера)
Отримання опитувань з бази даних (що належать даному користувачу)
Створення респондентів, їх параметрів (ім’я, вік, стать, тощо)
Заповнення даних опитування (співставлення відповідей конкретному респонденту)
Збереження результатів опитування
Таким чином, можна описати сценарій роботи системи в цілому: адміністратор системи на сайті створює користувачів, що мають доступ до роботи з системою. Після цього створює опитування (з питаннями та варіантами відповідей), назначає на нього інтерв’юерів і зберігає його через веб-сервіс в базу даних. Клієнт з мобільного пристрою через сервіс синхронізації отримує опитування, на які його назначив адміністратор системи. При початку опитування він створює опитуваного, заповнює його дані та відповіді на питання даного опитування. Через деякий проміжок часу або після деякої кількості опитаних респондентів, користувач викликає функцію синхронізації. Після цього адміністратор на сайті може побачити результати опитування.
Перша ітерація проекту закінчується запуском проекту на виконання і набором даних в базу для того, щоб дослідити поведінку системи при роботі з великим обсягом даних. Якщо всі показники (швидкість роботи, коректність відображуваної інформації, зручність при маніпуляціях в інтерфейсі) в нормі і задовольняє вимогам, можна починати наступну ітерацію. В даному випадку другою ітерацією буде розширення функціональності системи.
Друга ітерація
Нижче наведені зміни, що мають бути внесені в різні компоненти проекту під час другої ітерації.
База даних
Створення тригерів (захист від помилкового видалення, оновлення)
Налаштування резервного копіювання бази даних
Створення функцій авторизації користувачів
Веб-сервіс
Створення функцій авторизації користувачів
Розширення об’єктної моделі бази даних (створення додаткових методів взаємодії з базою даних)
Веб-сайт
Реалізація авторизації користувачів
Розширення можливостей перегляду статистики (фільтрація по різним параметрам, групам)
Контроль роботи інтерв’юерів (збір статистики)
По завершенні другої ітерації проекту система має виконувати усі необхідні задачі для контролю над процесом опитувань. Наприклад, для того, щоб бачити, наскільки завантажені користувачі системи і, відповідно, назначати їх на нові опитування, потрібно мати змогу відобразити загальну інформацію (див. Рис 7). Тут можна побачити усіх користувачів, що зареєстровані в системі, їх заплановані, активні та закриті опитування, кількість опитаних респондентів кожним з них по кожному опитуванню.
Рисунок 7. Загальна інформація по завантаженню користувачів
З іншого боку, може знадобитися можливість відображення переліку опитувань з основною інформацією про них з можливістю фільтрації по стану(Рис.8).
Рисунок 8. Перелік опитувань
Звичайно, однією з найважливіших задач являється можливість переглядати результати конкретного опитування, щоб мати змогу приймати обґрунтовані рішення відносно тих чи інших напрямків розвитку компанії (Рис.9)
Рисунок 9. Перегляд загальної інформації по опитуванню.
Також, можливо переглянути інформацію по одній з відповідей окремого питання, щоб мати змогу бачити, яка група людей найбільш зацікавлена саме в цьому варіанті. Наприклад, на рис. 10, показані усі респонденти, які вибрали одну й ту саму відповідь на одне з питань одного з опитувань.
Рисунок 10. Респонденти, що однаково відповіли на запитання
Можлива ситуація, коли адміністратору потрібно дізнатись, як відповідала на запитання конкретного опитування конкретна людина. Це може знадобитись для аналізу складних опитувань, що містять перевірочні питання, тощо (Рис. 11)
Рисунок 11. Відповіді респондента на опитування
Зі сторони інтерв’юера ситуація набагато простіша. Йому лише потрібно вибрати одне з опитувань, що йому назначив адміністратор (рис. 12), заповнити основні анкетні дані по респонденту (рис. 13) і, власне, провести процедуру опитування, вибираючи ті пункти (варіанти відповідей), що повідомляє йому респондент (рис. 14).
Рисунок 12. Перелік опитувань інтерв’юера
Рисунок 13. Створення респондента
Рисунок 14. Процес проведення опитування
3.4.2. Об’єктна модель системи
Система складається с чотирьох проектів, пов’язаних в одне рішення (Solution). Проекти відповідають абстрактним компонентам системи – веб-сервіс, веб-сайт, Windows Mobile програма та сервіс синхронізації даних. На рис. 15 відображена загальна схема об’єктної моделі системи.
Рисунок 15. Об’єктна модель системи
В самому початку ієрархії знаходиться рішення, яке містить у собі чотири проекти:
Core
Основна задача проекту – підвищити рівень абстракції при взаємодії клієнтського коду з базою даних. Таким чином, за допомогою цього проекту надається можливість систематизувати потоки даних, що проходять від клієнтів до сервера і в зворотному напрямку. Містить наступні об’єкти:
PollsService – веб-сервіс, містить в собі веб-методи, що працюють напряму з базою даних.
PollsData - об’єктна обгортка структури бази даних, підвищує рівень абстракції представлення бази даних.
User – клас, містить методи для роботи з користувачами системи.
Poll – клас, містить методи для роботи з опитуваннями.
Respondent – клас, містить методи для роботи з респондентами.
Question – клас, містить методи для роботи з питаннями.
PollsAdmin
Призначення проекту – забезпечення користувацького інтерфейсу для управління опитуваннями, користувачами, перегляду статистичних даних в різних варіаціях. Містить наступні об’єкти:
AnswerItem – елемент, відображає варіант відповіді на запитання конкретного опитування, кількість респондентів, що вибрали саме цю відповідь та відсоткове співвідношення щодо інших варіантів відповідей.
LoginControl – елемент управління, виконує функцію авторизації користувачів в системі.
PollPreview – елемент, відображає стислу інформацію про опитування.
PollsList – елемент-контейнер, містить у собі набір елементів PollPreview.
PollsResults – елемент, відображає результати конкретного опитування (перелік питань, варіанти відповідей на кожне з них та статистику по відповідям на кожен з варіантів).
QuestionItem – елемент, відображає інформацію про конкретне питання.
QuestionRes – елемент, відображає інформацію про результати відповідей на конкретне питання.
MasterPage – основна сторінка, від якої унаслідуються усі інші. Містить у собі елементи, що використовують усі інші сторінки (логотип із заголовком, елемент авторизації, головне меню, стилі оформлення, тощо).
Default – домашня сторінка, з неї починається користування сайтом. Відображає логотип, запит авторизації та головне меню.
Answers – сторінка, на якій відображено варіанти відповідей на обране питання (використовується в конструкторі опитувань).
Polls – сторінка містить у собі перелік опитувань (стислий вигляд) та інтерфейс для створення нового опитування (конструктор опитувань)
PollDetails – сторінка відображає повну інформацію про конкретне опитування (дата проведення, стан, перелік інтерв’юерів, перелік питань та варіантів відповідей на них, відсоткове співвідношення кількості опитаних до конкретного варіанту відповіді.
Questions – сторінка, що відображає перелік питань конкретного опитування (використовується в конструкторі опитувань).
Respondents – сторінка, що відображає перелік респондентів, що вибрали один і той самий варіант відповіді.
RespAnswers – сторінка, що відображає відповіді конкретного респондента на усі запитання обраного опитування.
Users – сторінка, що відображає перелік користувачів, зареєстрованих в системі, їх заплановані, закриті опитування та опитування, що проводяться в даний момент, кількість опитаних респондентів по кожному з них. Призначена для визначення продуктивності роботи різних користувачів системи.
PollsClient
Розміщується на мобільному пристрої інтерв’юера. Призначення – отримувати інформацію безпосередньо від джерела, зберігати локально і періодично відправляти на сервер. Надає інтерв’юеру мобільності (територіальну свободу та незалежність від потреби мати постійний зв’язок із серверною частиною. Містить наступні об’єкти:
Polls – локальна база даних, являється копією основної бази даних (деяких її таблиць). Призначена для зберігання інформації у файловій системі мобільного пристрою.
PollDataCache – компонент, що містить у собі методи та логіку процесу синхронізації сховищ даних.
LoginForm – вікно із полями для вводу облікових даних інтерв’юера. Виконує функцію авторизації користувача на мобільному пристрої.
PollForm – основне вікно програми, в ньому виводяться питання та варіанти відповідей на них.
RespForm – вікно додавання інформації про нового респондента в систему.
QuestItem – елемент управління, відображає та обробляє варіанти відповідей на конкретне питання.
PollsSyncLib
Проект являє собою бібліотеку, що містить у собі схему локального кешу даних та сервіс синхронізації. Містить наступні об’єкти:
PollDataCache – компонент, що містить у собі методи та логіку процесу синхронізації сховищ даних.
SyncContract – контракт синхронізації, описує правила синхронізації клієнта з сервером.
В цілому, після завершення двох ітерацій проекту, система знаходиться в стабільному, робочому стані. На відносно великих об’ємах робочої інформації, програмне забезпечення працює достатньо стабільно і задовольняє потребам користувачів в плані швидкості. Як клієнтська, так і серверна частина пройшли повний цикл тестування і повністю готові до роботи в реальних умовах.
ЗАГАЛЬНІ ВИСНОВКИ
В даній роботі висвітлюється питання впровадження сучасних інформаційних технологій в процеси проведення маркетингових та соціологічних опитувань. Актуальність досліджуваної тему доводять загальні тенденції до зросту чисельності опитувань серед населення та компаній, що займаються соціологічними дослідженнями. На даному етапі розвитку суспільства чи не найголовнішу роль має володіння інформацією. Також, важливий момент правильної інтерпретації, методів представлення інформації під потрібним кутом. Це дає можливість бачити повну картину щодо процесів, які відбуваються навколо. Та, якщо подивитись на ситуацію з іншого боку, то в деяких випадках (особливо в умовах конкуренції), відбувається боротьба не стільки за інформацію, скільки за можливість заволодіти цією інформацію першим. Виходячи з цього можна виділити декілька критеріїв успішного функціонування організації:
Ефективний пошук інформаційних джерел
Продуктивні методи здобуття інформації
Швидка обробка даних
Використання отриманих даних на благо організації
Уся задача зводиться до того, щоб якомога ефективніше організувати проведення цих етапів на налагодити їх взаємодію між собою. На щастя, теперішній рівень розвитку інформаційних технологій дозволяє втручатися в різні сфери діяльності з досить великим рівнем продуктивності. Але тут постає ще одна проблема: серед численних технологій, платформ, продуктів та сервісів, що існують на даний час важко вибрати ті, що допоможуть з найменшими витратами в плані часу та робочої сили створити повноцінний програмний продукт. Адже кожна з технологій має свої переваги та недоліки, що можуть бути більше або менше суттєвими при реалізації конкретного продукту.
В даній роботі проводиться дослідження передових методологій розробки програмного забезпечення, платформ розробки, технологій доступу до даних, та інших складових сучасного інформаційного простору з метою отримати відповіді на питання щодо конкретно сформульованої задачі. В результаті дослідження було виявлено найбільш ефективний набір інструментів для реалізації інформаційної системи.
В заключній частині, за допомогою вибраного інструментарію, було реалізовано складний програмний продукт, проведено його тестування. Розроблена система дозволяє створювати повноцінні маркетингові опитування із задаванням усіх необхідних для сучасних вимог параметрів та отримувати дані від джерела за допомогою мобільних пристроїв і в лічені секунді передавати ці дані безпосередньо в базу даних підприємства. Таким чином, зі звичайного алгоритму проведення опитувань просто видаляються такі етапи, як розповсюдження анкет (в паперовому варіанті) по інтерв’юерах та імпорт отриманих на паперах даних в базу даних за допомогою операторів. Такий спосіб реалізації дозволяє зекономити приблизно 50% часу, затраченого на опитування від самого початку і до кінця. Окрім економії часу, зникає необхідність в послугах, наприклад, операторського складу організації, що позитивно відгукається на фінансовій сфері компанії.
Виходячи з отриманих результатів, можна цілком впевнено сказати, що, навіть із затратами на програмне забезпечення для розробки системи та оплату роботи групи програмістів, економічна вигода від створеного продукту доволі значна.