Автоматизована система проведення маркетингових досліджень в Білгородському філії МЕСИ

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

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

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

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

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

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

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

Замовником даної системи виступає відділ маркетингу БФ МЕСИ. Однією з розв'язуваних завдань відділу маркетингу є проведення маркетингових досліджень. В даний час при реалізації цього завдання відділом маркетингу затрачуються певні ресурси, як матеріальні, так і людські. Процес проведення анкетування від підготовки до безпосереднього збору анкет у БФ МЕСИ проводиться вручну. Тому виникла необхідність у створенні Web-додатки, яка зможе автоматизувати бізнес-процеси проведення маркетингового дослідження.

Основна бізнес мета проекту - зниження витрат при проведенні маркетингових досліджень в БФ МЕСИ. Досягнення цієї мети планується за рахунок автоматизації процесу анкетування та процесу обробки даних за допомогою Web-додатки.

1. Вибір методології розробки

Створення будь-якого якісного програми супроводжує застосування будь-якої методології. Методологія [19] - це систематизована сукупність технічних прийомів, методик і принципів побудови, підтримки та / або удосконалення програмного забезпечення. Методологія створює основу для обміну інформацією, надає інструментарій та технічні прийоми для організації надійного, повторюваного процесу розробки ПЗ. Методологія поділяє весь обсяг роботи на організовані фази та / або етапи, які потім, у свою чергу, діляться на план та завдання, вхідні дані та результати, технологічні прийоми, інструменти, ролі членів команди в процесі розробки продукту. Набір систематизованих зразків робіт представлений у вигляді шаблонів, маршрутів, сценаріїв дій і прикладів організації дій. Зразки робіт легко адаптуються до проектів будь специфіки, створюючи надійну базу для формування структури організації. На основі обраної методології проводиться вибір конкретних проектних інструментів і програмних засобів. Найбільш відомими і популярними методологіями для організації якісного процесу розробки додатків є Rational Unified Process (RUP) і Microsoft Solutions Framework (MSF) [3]

Rational Unified Process (RUP) [14] пропонує ітеративну модель розробки, що включає чотири фази: початок, дослідження, побудова та впровадження. Кожна фаза може бути розбита на етапи (ітерації), в результаті яких випускається версія для внутрішнього або зовнішнього використання. Проходження через чотири основні фази називається циклом розробки, кожен цикл завершується генерацією версії системи. Якщо після цього робота над проектом не припиняється, то отриманий продукт продовжує розвиватися і знову мине ті ж фази. Суть роботи в рамках RUP - це створення і супровід моделей, а не паперових документів, тому цей процес прив'язаний до використання конкретних засобів моделювання (UML), а так само конкретної технології проектування та розробки (об'єктно-орієнтований аналіз, object-oriented analysis, OOA , об'єктно-орієнтоване програмування, object-oriented programming, OOP). RUP - це технологічний процес, що дозволяє підвищити продуктивність діяльності команди і уніфікувати процес розробки складних інформаційних систем, надаючи готові моделі організації роботи та шаблони документів. Метою RUP є створення умов для розробки продуктів, які повністю відповідають вимогам замовників. Схеми планування, надані RUP, дозволяють раціоналізувати процес розробки і тим самим дотримуватися заздалегідь обумовлених термінів і бюджету проекту.

MicrosoftR Solutions Framework (MSF) - це пакет докладних керівництв "як діяти" при розробці, як додатків, так і інфраструктурних проектів. Поряд з допомогою у виборі технології, MSF робить акцент на людському факторі, а також окремих складових процесу розробки. Система включає принципи, моделі і приклади проектів, які допомагають ідентифікувати найбільш типові помилки і адресувати їх для коригування відповідальним за дану частину проекту. Дисциплінований підхід критично важливий для розробки якісних бізнес-рішень у відповідності з погодженими термінами, вимогами і бюджетом. MSF схожа з RUP, так само включає чотири фази: аналіз, проектування, розробка, стабілізація, є ітераційної, припускає використання об'єктно-орієнтованого моделювання. MSF у порівнянні з RUP більшою мірою орієнтована на розробку бізнес-додатків.

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

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

Рис.1.1 Моделі життєвого циклу

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

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

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

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

У моделі процесів MSF зібрано все найкраще з каскадної і спіральної моделей: планування на основі проміжних контрольних точок і передбачуваність з водопаду моделі поряд зі зворотним зв'язком і колективним творчим підходом, характерними для спіральної моделі.

Модель процесів MSF складається з п'яти чітко визначених етапів:

• створення загальної картини програми;

• планування;

• розробки;

• стабілізації;

• розгортання.

Кожен етап завершується контрольною точкою.

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

На етапі створення загальної картини програми команда вирішує різні завдання.

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

• Визначення структури проекту - визначення адміністративної структури проектної команди і стандартів управління проектом.

• Визначення бізнес-цілей - аналіз бізнес-завдання і можливостей для виявлення цілей створення продукту.

• Оцінка існуючої ситуації - аналіз поточного стану і оцінка розриву між реальним і очікуваним станом справ. Мета такого аналізу - сформулювати перелік завдань і визначити напрямок розвитку проекту.

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

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

• Розробка концепції вирішення - створення базової концепції вирішення, тобто «кістяка» рішення, яке стане основою майбутнього продукту. Концепція створюється на основі зібраних вимог.

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

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

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

Загальна картина і область дії рішення:

• формулювання завдань і бізнес-цілей;

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

• найбільш загальне визначення вимог користувачів;

• профілі користувачів, які визначають, хто буде працювати з продуктом;

• документ загальної картини і визначення області дії;

• концепція рішення, що описує спосіб планування проекту;

• стратегії проектування рішення.

Структура проекту:

• опис усіх ролей команд MSF і списки членів команд;

• структура проекту і стандарти процесів, яких повинна дотримуватися команда.

Оцінка ризику:

• попередня оцінка ризику;

• список попередньо визначених ризиків;

• плани усунення або зниження впливу виявлених ризиків.

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

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

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

Етап планування складається з трьох стадій.

• Концептуальний дизайн. Завдання розглядається з точки зору користувача і бізнес-вимог і визначається у вигляді сценаріїв використання системи.

• Логічний дизайн. Завдання розглядається з точки зору проектної команди, і рішення визначається як набір сервісів.

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

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

Процес розробки

На етапі розробки команда виконує кілька завдань.

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

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

• Розробка компонентів рішення. Розробка основних компонентів рішення та їх адаптація у відповідності з потребами рішення.

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

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

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

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

Після розгортання команда виконує аналіз проекту та проводить опитування, щоб з'ясувати рівень задоволений кістки замовника. Етап розгортання завершується контрольної точкою «Рішення розгорнуто».

Як інструмент моделювання буде використовуватися UML (Unified Modeling Language) - стандартна мова, застосовуваний для моделювання інформаційних систем різної складності - від великих корпоративних ІТ-систем до розподілених систем, заснованих на Web [5].

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

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

• опису специфікацій інформаційної системи. UML допомагає будувати точні, однозначні і повні моделі;

• конструювання моделей ІТ-системи, які можуть безпосередньо перетворюватися в текст на різних мов програмування;

• документування моделей програмної системи, висловлюючи вимоги до системи на стадіях розробки та розгортання

Основні риси UML:

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

• складається з набору нотацій і правил моделювання програмних систем різного ступеня складності;

• дає можливість створювати прості, добре документовані і легкі для розуміння моделі ПЗ;

• не залежить як від мови програмування, так і від платформи.

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

Моделі або подання використовуються для наочного зображення складної інформаційної системи, причому різні аспекти інформаційної системи відображають у вигляді UML-уявлень (UML views). Зазвичай застосовуються такі уявлення:

• користувача уявлення (user view) виражає цілі і завдання системи з погляду користувачів і їхніх вимог до системи. Це уявлення відноситься до частини системи, з якою взаємодіє користувач. Користувача подання також називають представленням у вигляді набору діаграм UseCase

• Структурний подання (structural view) відображає статичне або неробочий стан системи. Його також називають поданням дизайну (designview).

• Представлення поведінки (behavioral view) відображає динамічний або змінюється стан системи. Його іноді називають подання процесів (process view).

• Представлення реалізації (implementation view) представляє структур} логічних елементів системи.

• Представлення оточення (environment view) відбиває розподіл фізичних елементів системи. Оточення системи визначає її функції з точки зору користувачів. Представлення оточення також називають поданням розгортання (deployment view).

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

Застосовуються наступні UML-діаграми для зображення різних уявлень системи:

• діаграми класів (class diagrams) містять класи та їх зв'язки. Зв'язки (асоціації) між класами зображуються двонаправленими сполучними лініями;

• діаграми об'єктів (object diagrams) зображують різні об'єкти системи і їх взаємозв'язку;

• діаграми ВІС (use case diagrams) показують набір функцій, який система надає зовнішніх об'єктах;

• діаграми компонентів (component diagrams) відображають уявлення реалізації системи. Вона містить різні компоненти системи та їх взаємозв'язку, такі, як вихідний код, об'єктний код і виконуваний код;

• діаграми розгортання (deployment diagram) показують відповідність програмних компонентів версій сайту фізичної реалізації системи;

• діаграми колективної взаємодії (collaboration diagrams) представляють собою набір класів і відправляються і приймаються ними повідомлень;

• діаграми послідовностей (sequence diagrams) описують взаємодію між класами - посдедовательность повідомлень, якими обмінюються класи;

• діаграми станів (state diagrams) описують поведінку класу в моментобращенія до нього зовнішнього процесу або об'єкта. Вона відображає стану та відповідні сигнали класу при виконанні дії.

2. Створення загальної картини рішення

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

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

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

• існуюча - Наявна в установі;

• інформація з різних видів опитувань службовців.

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

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

Найбільш поширеними формами опр оса є:

• структурований;

• напівструктурованих;

• групові обговорення і зустрічі;

• анкети.

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

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

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

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

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

Відповідно з основними стратегічними цілями МЕСИ і його поточними завданнями відділ маркетингу регіональної структури у своїй повсякденній діяльності зобов'язаний реалізовувати такі основні завдання:

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

2. Проведення всього комплексу ринкових досліджень, пов'язаних з ринком освітніх продуктів і послуг в регіонах, регіонального ринку праці, споживачами регіональних структур, як за затвердженим планом-графіком досліджень, так і за спеціальними вказівками відділу маркетингу.

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

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

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

6. Періодична консультація з відділом маркетингу головного вузу з питань маркетингової діяльності регіональної структури.

7. Розробка довгострокових (на рік) і поточних планів (на місяць) регіонального маркетингу та погодження з відділом маркетингу головного вузу.

8. Розробка та затвердження структури та обсягу бюджету маркетингу з відділом маркетингу головного вузу.

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

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

11. Створення та оперативне ведення баз даних «Споживачі» і «Конкуренти».

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

13. Розробка пропозицій щодо формування / коригуванні позитивного іміджу МЕСИ у свідомості регіональних Споживачів / Студентів і єдиної корпоративної культури, безпосередню участь у їх практичному здійсненні з використанням засобів реклами.

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

При проведенні маркетингових досліджень величезна частина часу витрачається на проведення анкетування та подальшу обробку отриманих даних. Відповідно до Положення про маркетингової діяльності регіональних структур відділ маркетингу повинен проводити наступні види анкетування [2]:

1. Старшокласники і випускники ссузів (довузівські заходи) (анкета + форма звіту - Word);

2. Абітурієнти, в тому числі відвідувачі ДОД (анкета + форма звіту - Word);

3. Студенти 1, 5 курсів (анкета + форма звіту - Word);

4. Студенти 2, 3, 4 курсів (анкета + форма звіту - Word). Студенти (якість навчання) (анкета + форма звіту - Word);

5. Студенти - екстерни (анкета + форма звіту - Word);

6. Слухачі семінарів, курсів і т.д. (Анкета + форма звіту - Word).

7. Анкетування роботодавців (визначення ставлення до екстернату) (анкета + форма звіту - Word);

8. Анкетування роботодавців (виявлення потреби у фахівцях і вимог що пред'являються до їх підготовки) (анкета + форма звіту - Word).

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

2.2 Область дії

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

Основна мета проекту - це зниження витрат при проведенні маркетингових досліджень.

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

• Підготовка анкет

• Проведення анкетування

• Обробка даних

• Зберігання та подальший пошук

Для даної системи визначено такі учасники:

• Адміністратор системи

• Співробітник відділу маркетингу

• Звичайний користувач (абітурієнт, студент, роботодавець)

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

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

Рис. 2.1 Загальна діаграма використання для системи

Реалізація системи передбачає вирішення таких завдань:

• створення макету анкети;

• зручне редагування існуючої анкети;

• експорт та імпорт анкети

• проведення анкетування (заповнення анкет);

• обробка результатів анкетування;

• перегляд статистики (формування звітів).

• Ведення бази даних, в якій зберігаються результати анкетування.

2.3 Створення концепції вирішення

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

В якості браузера буде використовуватися "тонкий клієнт". «Тонкі клієнти» - це термінальні станції, за якими працюють користувачі, а всі програми при цьому виконуються на сервері. Таким чином, дане рішення грунтується на багато користувачів операційної системи, в нашому випадку це Windows Server 2003, виконанні всіх додатків на сервері під управлінням IIS (Internet Information Services).

В якості платформи для розробки буде використовуватися технологія. NET. Вона відкриває широкі перспективи вдосконалення способів розробки корпоративних додатків. Visual Studio. NET забезпечує каркас загального середовища, на якій базуються кілька мов. Середа Visual Studio. NET також більше, ніж попередні версії, орієнтована на роботу в Інтернеті - серйозну увагу приділено в ній Web-служб, XML і розподіленим додаткам.

У якості СУБД буде використовуватися Microsoft SQL Server 2005, представляє нове покоління масштабованих рішень в області систем управління базами і сховищ даних для задач, що вимагають швидкого отримання та аналізу інформації. Він націлений на вирішення широкого кола завдань у всіх сферах бізнесу, в тому числі і в електронній комерції.

Переваги Microsoft SQL Server 2005:

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

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

Швидкість побудови рішень. SQL Server 2005 зменшує час створення, розгортання і виходу на ринок сучасних програм для завдань бізнесу, електронної комерції, використовує вбудований відладчик T-SQL. Удосконалює і прискорює процес пошуку даних, спрощує управління, дозволяє використовувати створювані користувачем функції в інших програмах, надає широкі можливості для створення Web додатків.

Рекордні показники швидкості роботи. Ще до остаточного виходу на ринок SQL Server 2005 встановила новий світовий рекорд по продуктивності, далеко випередивши конкуруючі рішення на різних платформах.

Основні можливості

SQL Server 2005 інтегрується в існуючі системи без програмування, використовуючи вбудовану підтримку W3C стандартів, включаючи XML, Xpath, XSL і HTTP. Дозволяє перегляд і доступ до реляційних даних, використовуючи техніку простого зіставлення XML елементів і атрибутів реляційної схеми.

SQL Server 2005 здійснює доступ до даних за допомогою URL (використовуючи в запитах мову SQL, XML шаблони або Xpath), повертає XML об'єкти з SQL запитів і управляє їх формою, використовуючи опції форматування.

SQL Server 2005 підтримує застосування XML для виділення, вставки, оновлення та видалення табличних даних з будь-якого місця навіть через міжмережевий екран (firewall), що дозволяє передавати, перетворювати і завантажувати дані цілком з будь-якого джерела в реляційні таблиці SQL Server 2005. Продукт працює з XML документами, як з SQL таблицями, використовуючи T-SQL і вбудовані процедури.

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

SQL Server 2005 дозволяє аналізувати зібрані реляційні і OLAP дані, включаючи вхідні потоки та історію звернень, щоб зрозуміти тренди і сформувати прогнози, виконує аналіз великих обсягів даних (10М + записів), за рахунок пов'язаного зберігання. При цьому продукт залишає сервер доступним для інших завдань при оновленні індексів, підтримує швидке архівування з невеликими витратами системних ресурсів, архівуючи лише змінені елементи, дозволяє переміщати і копіювати бази даних і об'єкти між серверами, використовуючи спеціальні майстри.

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

Вбудований MDX конструктор, підтримка мереж SAN, обробка OLAP, алгоритми самонастроювання і управління, підтримка функцій створюваних користувачем, інтеграція з Active Directory - все це збільшує можливості і області застосування SQL Server 2005.

Повнотекстовий пошук через Web або інтрамережа для форматованих документів (Word, Excel, HTML).

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

Запити англійською мовою.

Сервіси аналізу та безпеки. MS SQL 2005 закриває дані, використовуючи системи безпеки для масивів та осередків, і обмежує доступ до спеціальних наборів осередків.

Сервіси перетворення даних. MS SQL 2005 імпортує і експортує дані та ключі між підтримуваними базами даних, програмує багатофазну підкачування даних і зберігає пакети DTS як код Visual Basic.

Безпека. MS SQL 2005 включає підтримку SSL з'єднань, має сертифікат безпеки С2. При установці за замовчуванням встановлюється високий рівень захисту. У травні 2005 року Microsoft SQL Server 2000 Enterprise Edition отримала сертифікат Федеральною службою з технічного та експортного контролю про відповідність оціночним рівнем довіри Оуд 1 (посиленому) при роботі під управлінням Microsoft Windows Server 2003 Enterprise Edition, у відповідності з керівним документом «Безпека інформаційних технологій. Критерії оцінки безпеки інформаційних технологій »(Гостехкомиссией Росії, 2002р.). Сертифікат підтверджує, що Microsoft SQL 2000 Enterprise Edition може використовуватися для побудови автоматизованих систем до класу захищеності 1Г включно.

З'єднання OLAP кубів на різних серверах для аналізу продуктивності. Підтримується безпечний доступ до даних куба через Internet.

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

3. Планування

3.1 Загальні відомості етапу планування

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

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

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

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

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

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

3.2 Концептуальне проектування

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

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

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

3.2.1 Опис моделі бізнес процесів AS - IS

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

Рис. 3.1. Загальний план анкетування

Планування проведення анкетування:

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

Рис. 3.2. Планування проведення анкетування

Створення анкети

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

Рис. 3.2. Створення анкети

Проведення анкетування

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

Рис. 3.3. Проведення анкетування

Обробка даних

Призначаються відповідальні особи, які переглядають зібрані анкети, аналізують їх, і на підставі проведеного аналізу отримують результати. Аналіз зібраних даних здійснюється з використанням Microsoft Excel. На підставі зібраних даних формуються звіти маркетингового дослідження, які оформляються у відповідності з шаблоном.

Рис. 3.4. Обробка даних

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

3 .2.2. Побудова діаграми варіантів використання

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

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

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

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

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

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

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

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

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

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

На наступній діаграмі описується процес створення анкети:

Рис. 3.5. Діаграма варіантів використання Створити анкети

Рис. 3.7. Діаграма варіантів використання Опублікувати анкети

Рис. 3.8. Діаграма варіантів використання Створити звіти

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

3.3 Логічне проектування

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

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

3.3.1 Створення модулів і сервісів

Модульна декомпозиція

• Модуль "Створення анкет"

• Модуль "Опублікування анкет"

• Модуль "Анкетування"

• Модуль "Створення звітів"

• Модуль "Перегляд звітів"

У модулі "Створення анкет" реалізовані наступні функції:

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

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

• Видалення анкет.

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

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

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

Модуль "Опублікування анкет" дозволяє розміщувати на сторінці сайту різні анкети, задавати інтервали проведення анкетування.

Модуль "Анкетування" дозволяє користувачам проходити різні види анкетування.

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

Модуль "Перегляд звітів" дозволяє проаналізувати введені дані та переглянути звіти на підставі створених шаблонів

3.3.2 Логічна модель даних

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

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

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

Після визначення сутностей слід визначити необхідні атрибути - вони описують сутності рішення.

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

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

Дана нотація була введена Ченом (Chen) і отримала подальший розвиток у роботах Баркера (Barker). Нотація Чена надає багатий набір засобів моделювання даних, включаючи власне ERD, а також діаграми атрибутів і діаграми декомпозиції. Ці діаграмні техніки використовуються насамперед для проектування реляційних баз даних (хоча також можуть з успіхом застосовуватися і для моделювання як ієрархічних, так і мережевих баз даних).

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

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

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

• забезпечення зберігання інформації в єдиному місці (навіть якщо вона використовується в різних комбінаціях);

• використання цієї інформації різними додатками.

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

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

1. 1 * 1 (один-до-одного). Відносини даного типу використовуються, як правило, на верхніх рівнях ієрархії моделі даних, а на нижніх рівнях зустрічаються порівняно рідко.

2. 1 * n (один-до-багатьох). Відносини даного типу є найбільш часто використовуваними.

3. n * m (багато-до-багатьох). Відносини даного типу зазвичай використовуються на ранніх етапах проектування з метою прояснення ситуації. У подальшому кожна з таких відносин має бути перетворено в комбінацію відносин типів 1 і 2 (можливо, з додаванням допоміжних сутностей і з введенням нових відносин).

У результаті дослідження use case були виділені наступні сутності:

1. Анкета

2. Питання

3. Відповідь

4. Опитування

5. Користувач

6. Ролі

7. Результати

Анкета містить список всіх питань і, в той же час один і той же питання може бути використана в різних анкетах. Тому сутності Анкета і Питання полягають у відносинах «багато до багатьох»

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

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

Анкетування може проходити довільну кількість користувачів, проте користувач може брати участь тільки в одному опитуванні. Тому сутності Користувач і Опитування перебувають у відношенні «один до багатьох».

Один користувач може мати кілька ролей, з іншого боку одна і та ж роль може належати різним користувачам. Тому сутності Користувач і Ролі перебувають у відношенні «один до багатьох».

Користувач може бути автором кількох анкет, проте анкета може належати тільки одному авторові. Тому сутності Користувач і Анкета перебувають у відношенні «один до багатьох».

У результаті анкетування користувач вибирає певний варіант відповіді на поставлене питання, в результаті чого формуються результати відповідей, які можуть належати тільки даному опитуванням, з іншого боку опитування містить деяку кількість результатів відповідей. Тому сутності Опитування й Результати перебувають у відношенні «один до багатьох».

Отже, отримуємо такі відносини сутностей:

«Анкета»: «Питання» = «багато до багатьох»

«Питання»: «Відповідь» = «один до багатьох»

«Анкета»: «Опитування» = «один до багатьох»

«Користувач»: «Опитування» = «один до багатьох»

«Користувач»: «Ралі» = «багато до багатьох»

"Опитування": «Результати» = «один до багатьох»

Логічна модель даних представлена ​​на малюнку

Рис. 3.9 Діаграма сутність-зв'язок

3.4 Фізичне проектування

3.4.1 Побудова діаграми класів

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

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

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

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

Центральне місце в ООАП займає розробка моделі системи у вигляді діаграми класів. Нотація класів у мові UML проста і інтуїтивно зрозуміла всім, хто коли-небудь мав досвід роботи з CASE-інструментаріями. Схожа нотація застосовується і для об'єктів - екземплярів класу, з тією різницею, що до імені класу додається ім'я об'єкта і вся напис підкреслюється.

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

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

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

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

На наступному малюнку показана діаграма класів

Рис. 3.10. Діаграма класів

3.4.2. Модель для користувача інтерфейсу

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

• стандартний користувальницький інтерфейс Windows;

• Web-інтерфейс;

Стандартний інтерфейс Windows

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

Web-інтерфейс

У Microsoft. NET користувальницький Web-інтерфейс розробляється засобами ASP.NET. Ця технологія надає багату функціями середовище, що дозволяє створювати складні Web-інтерфейси. Ось лише деякі з можливостей ASP.NET:

• уніфікована середовище розробки;

• прив'язка даних до призначеного для користувача інтерфейсу;

• інтерфейс на основі компонентів з елементами управління;

• вбудована модель безпеки каркаса. NET;

• широкі можливості щодо підтримки кешування і управління станом;

• доступність, продуктивність і масштабованість Web-обробки даних)

Передбачається що система буде використовувати Web-інтерфейс

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

3.4.3 Створення фізичної моделі даних

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

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

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

Типи фізичних моделей даних

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

• БД на плоских файлах, або неструктуровані БД. У такій базі даних всі дані розташовуються в одному файлі у вигляді набору рядків і стовпців. У цій архітектурі відсутній зв'язок між різними плоскими файлами, оскільки жодна з цих БД нічого не знає про інших. Вона підтримує швидке оновлення і читання даних за рахунок методу індексування ISAM (indexed sequential access method - індексно-послідовні і метод доступу). Технологія ISAM застосовується в успадкованих мейнфреймових БД і невеликих базах даних, розміщених на ПК.

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

• Реляційні БД. Тут дані зберігаються в наборі таблиць і стовпців. Реляційні бази даних поєднують переваги плоских файлів і ієрархічних баз даних, забезпечуючи гарну продуктивність і гнучкість у зберіганні даних. Завдяки можливості визначати зв'язки між таблицями на основі унікальних значень, реляційні бази даних - одні з найпопулярніших. Однак важливо розуміти, що інші моделі також застосовуються і що розробникам систем масштабу підприємства іноді доводиться працювати з декількома типами баз даних одночасно. У реляційній моделі основна увага приділяється збереженню, вибірці і забезпечення цілісності даних. Структурований мову запитів SQL (Structured Query Language) дозволяє ефективно використовувати зв'язані елементи даних незалежно від того, в одній або кількох таблицях вони зберігаються. Цілісність даних забезпечується механізмом правил (rules) і обмежень (constraints).

У Білгородському філії МЕСИ в даний час для зберігання динних застосовується Microsoft SQL Server 2000. Тому для системи було вибрано перевагу реляційної бази даних. Фізична модель відображає цільову середу реалізації.

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

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

Визначення таблиць

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

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

Традиційний формат взаємодії з реляційними даними - ANSI рядки, а мова - SQL. Ця мова, нагадує англійську і представляє операції, що їх з базою даних, у вигляді зрозумілих людині виразів, таких, як Insert (Вставка), Update (оновлення) і Delete (видалення). Більшість баз даних задовольняють ANSI-стандарту SQL, хоча його версії і розширення в різних системах відрізняються.

Визначення стовпців

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

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

1. Users.

2. UserRoles

3. Roles

4. Form

5. Common

6. Question

7. Answer

8. Survey

9. Results

Таблиця Users містить опис користувачів.

Таблиця № 3.1

Таблиця Roles містить опис ролей користувача

Таблиця № 3.2

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

Таблиця № 3.3

Таблиця Form містить необхідну інформацію про анкету

Таблиця № 3.4

Таблиця Question містить список питань

Таблиця № 3.5

Таблиця Answer містить список відповідей на конкретне запитання

Таблиця № 3.6

Так як Анкета складається з безлічі питань, а один і той же питання може бути присутнім у різних анкетах, то в результаті нормалізації була виділена таблиця Common, в якій міститься список відповідей на конкретне питання.

Таблиця № 3.7

Таблиця Survey містить опубліковані анкети за якими в даний момент відбувається анкетування

Таблиця № 3.8

Рис. 3.11. Фізична модель даних

4. Розробка

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

«Розробка» - третя стадія моделі процесу розробки MSF. Вона слідує за стадією «Планування», яка завершується схваленням плану проекту. До цих пір проектна група займалася в основному концепцією, архітектурою продукту і плануванням. На стадії «Розробка» основне завдання - виконання проекту.

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

Стадія «Розробка» завершується написанням коду і випуском першої версії додатка. Результати етапу «Завершення розробки» такі:

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

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

 проектна група та інші учасники проекту згодні з тим, що всі реалізовані функціональні можливості відповідають концепції і функціональним специфікаціям, і реалізовані успішно;

 завершена підготовка до тестування продуктивності продукту і його стабілізації.

Фаза «Розробка» багато в чому схожа з іншими стадіями моделі процесу розробки MSF. Наприклад, фаза «Планування» завершується підготовкою функціональних специфікацій. Ці документи стають вихідними для стадії «Розробка». Крім того, вони необхідні для оцінки різних характеристик процесу розробки. Пам'ятайте, що ці документи не залишаються незмінними - вони цілком можуть зазнавати зміни по мірі виконання стадії «Розробка». Ця стадія завершується, коли підготовлені переглянуті варіанти цих документів, а також:

 вихідний код і виконують модулі проекту;

 результати дослідження продуктивності;

 основні складові процесу тестування.

Стадію «Розробка» програмісти часто називають «справжньою роботою». Дійсно, основне її завдання - створення працюючого продукту.

Проектування архітектури продукту на стадії «Проектування» визначає успіх його реалізації на стадії «Розробка». Стів Мак-Коннелл у своїй книзі «Software Project Survival Guide »описує зв'язок цих стадій, порівнюючи їх з рухом проти течії річки і за течією. Розробка архітектури на стадії «Планування», вважає він, схожа на рух вгору за течією - чим вище ви заберетеся, тим простіше буде сплавлятися вниз на стадії «Розробка». Цей процес, що починається після завершення стадії проектування та закінчується випуском продукту, буде тим успішніше і простіше, ніж краще продумана архітектура.

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

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

Як засіб розробки було прийнято рішення використовувати Microsoft Visual Studio. NET

4.2 Вибір інструментального засобу розробки

Система Visual Studio. NET сьогодні дозволяє розробникам створювати Інтернет-додатки нового покоління [18]. Забезпечуючи найсучаснішу і багатофункціональну середовище розробки, система Visual Studio. NET надає розробникам кошти для інтеграції програм з будь-якими операційними системами і мовами програмування. За допомогою Visual Studio. NET можна легко здійснити перетворення наявної бізнес-логіки у веб-служби XML, що допускають повторне використання завдяки інкапсуляції процесів і надання доступу до них з додатків, незалежно від того, на якій платформі вони працюють. Розробники можуть легко об'єднувати будь-яке число веб-служб, каталогізованих і доступних у різних каталогах UDDI, забезпечуючи міцну базу для служб і бізнес-логіки створюваних додатків.

У своєму універсальному підході до мов Visual Studio. NET підтримує VB.NET, C #, C + + і J #. C # - абсолютно нову мову. VB.NET настільки змінився, що його можна вважати практично новою мовою. Здебільшого мови Visual Studio використовують оновлену IDE-середовище, а для створення програмних компонентів і елементів призначеного для користувача інтерфейсу застосовуються один або декілька з трьох форматів: Windows-форми, Web-форми і Web-служби. В усіх мовах застосовується. NET Framework Classes - бібліотека класів, які забезпечують підтримку "рідних" для середовища Visual Studio функцій.

У Visual Studio. NET всі дороги ведуть до загальномовних середовищі виконання (Common Language Runtime, CLR). Незалежно від використовуваної мови - C + +, C #, VB.NET або J # - зрештою програма перетворюється на формат мови MSIL (Microsoft Intermediate Language - проміжний мова Microsoft), який інтерпретується CLR-компілятором. Visual Studio. NET - це по-справжньому інтегрована середовище розробки, незалежно від вибраної мови або типу створюваного додатка, повністю об'єктно-орієнтована і побудована на єдиній платформі (. NET Framework). Загальний вигляд і логіка роботи з інструментальними засобами в Visual Studio. NET в основному збережені, а величезна кількість коду і велика частина інструментів розробки (зокрема, засоби проектування, редагування та налагодження) можуть Visual Studio. NET - це також спроба Microsoft вплинути на майбутнє Web-служб і всього ринку ПЗ для розробників. Компанія зробила всі можливі зусилля, щоб надати звичайному програмісту інструментальні засоби для створення Web-служб; в той же час не залишилися без уваги засоби розробки серверних і Web-додатків, прикладних програм для роботи на мобільних пристроях і в локальній мережі.

Нова комбінація ASP.NET і Web-форм істотно поліпшена. Замість об'єднання HTML, ASP-коду і тексту сценаріїв в єдиний файл Web-форми дозволяють рознести HTML і код програмної логіки в різні файли, які потім можна успішно скомпілювати.

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

Рис. 4.1. Microsoft Visual Studio 2003

Найбільш помітна особливість Visual Studio. NET - це підтримка Web-служб. Для представлення даних в. NET Framework за замовчуванням використовується мова XML, який до того ж прекрасно пов'язаний з протоколом SOAP.

Microsoft автоматизувала практично всі етапи створення та використання Web-служб. Програміст може практично нічого не знати про SOAP, WSDL і UDDI і при цьому створювати працюють Web-служби.

На додаток до присутніх у Visual Studio. NET можливостям рівня підприємства, наприклад, надійної системи налагодження, версія Enterprise Architect містить засоби підтримки групової розробки проектів, а також Enterprise Templates (шаблони підприємств) і систему моделювання Visio. Надається також повна підтримка мови UML із застосуванням восьми типів діаграм та вільної форми.

4.3 Створення модулів

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

Ітерації розподілялися відповідно до виділених модулями. Далі описується послідовність робіт. Тому була вибудувана чітка послідовність у реалізації Системи. Сам процес кодування і використання алгоритмів не регламентувався. Це прерогатива програміста.

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

Рис. 4.1. Створення анкети

Рис. 4.2. Створення / редагування питань

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

Рис. 4.2. Опублікування анкети.

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

Рис. 4.3. Проходження анкетування

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

Рис. 4.5. Звіт про анкетуванні

5. Економічне обгрунтування замовленого рішення

5.1 План аналізу економічної ефективності

Для подальшого розвитку Системи необхідно розрахувати економічну ефективність проекту. Для цього необхідно вибрати напрямок поширення Системи. Замовником системи виступив Білгородський філія МЕСИ. Зробимо розрахунок економічної ефективності проекту з точки зору замовного проекту. Структура економічної частини при створенні програмного забезпечення на замовлення фірми наступна:

1. Техніко-економічне обгрунтування розробки ПЗ;

2. Розрахунок витрат на розробку ПЗ;

3. Вартість впровадження ПЗ Замовником;

4. Витрати замовника при експлуатації ПЗ;

5. Ефективність впровадження для Замовника ПЗ;

6. Правові аспекти.

5.2 Техніко-економічне обгрунтування розробки ПЗ

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

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

5.3 Розрахунок витрат на розробку ПЗ

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

Витрати на розробку.

Оскільки Система розроблялася повністю за методологією MSF, було вирішено відмовитися від традиційної системи оцінки витрат (ТЗ, ескізний проект, технічний проект, робочий проект, впровадження) на користь більш прийнятною методики. Фази і зміст робіт представлені в таблиці 3.1:

Таблиця № 5.1

Загальна трудомісткість розробки ПЗ розраховується за формулою:

,

де - Загальна трудомісткість розробки, дн; Т i - трудомісткість за стадіями, дн; n - кількість стадій розробки.

На створення Системи було витрачено 53 робочих дня. Оцінка витрат включає такі пункти:

• основна і додаткова зарплати;

• відрахування на соціальні потреби;

• вартість інструментальних засобів;

• накладні витрати.

Фонд оплати праці

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

Таким чином, основна заробітна плата (З _осн) при виконанні НДР розраховується за формулою:

,

де З _ср.днj - середньоденна зарплата j-го співробітника, руб.; n - кількість співробітників, які беруть безпосередню участь у розробці ПЗ.

Середньоденна зарплата розробника визначена з розрахунку 7000 руб. на місяць і дорівнює:

З _{СР дн. р.} = 7000/20 = 350 руб. / день

На консультації заплановано:

24 години - дипломний керівник,

3 години - консультант з економіки.

Заробітна плата дипломного керівника становить 100 руб / год. Отже, зарплата дипломного керівника:

З _рук = 24 * 100 = 2400 руб.

Заробітна плата консультанта з економіки складає 80 руб / год.

З _конс = 3 * 80 = 240 руб.

Отримуємо, основна заробітна плата при виконанні НДР дорівнює:

З _осн = З _раз + З _рук + З _конс = 350 * 53 + 2400 + 240 = 21290 руб.

Додаткова заробітна плата дорівнює 10% від основної, отже:

З _доп = (10 * З _осн) / 100 = (10 * 21 290) / 100 = 2129 руб.

Разом основна і додаткова заробітна плата становить:

З _заг = 21290 + 2129 = 23419 руб.

Відрахування на соціальні потреби становлять на сьогоднішній день 26% від загального фонду заробітної плати, отже:

Про _соц = З _заг * 0,26 = 23419 * 0,26 = 6088,94 рублів.

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

Вартість машинного часу З _ОМВ залежить від собівартості машино-години роботи ЕОМ З _МЧ, а також часу роботи на ЕОМ Т _ЕОМ, і включає амортизацію ЕОМ та устаткування, витрати на електроенергію,

Собівартість машино-години ЕОМ дорівнює:

Час використання обладнання:

Витрати на обладнання.

,

де А _М - амортизаційні відрахування, руб.; Про _ф - вартість ЕОМ та устаткування, руб.; Н _ам - Норма амортизації,%; Т _м - час використання обладнання, дні

Витрати на електроенергію.

,

Таким чином, вартість машинного часу на підготовку та налагодження програм одно:

Використання інструментарію.

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

Норма амортизації для СПО 30%, а час використання 36,55 днів.

Використані засоби представлені в таблиці 3.2.

Таблиця 5.2

А _і = ((Про _ф * Н _ам) / (365 * 100)) * Т _м = ((28501,8 * 30) / (365 * 100)) * 36,55 = 856,22 руб.

де О _ф - вартість використаних коштів;

Н _ам - норма амортизації;

Т _м - час використання інструментарію, дні.

Отже, кошторис витрат на розробку наведена в таблиці 5.3:

Таблиця № 5.3

5.4 Вартість впровадження ПЗ Замовником

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

• програмного забезпечення Ц _по;

• інструментальних засобів Ц _ис;

• ЕОМ, інших апаратних засобів і мережевого обладнання До _ЕОМ;

• навчання персоналу До _осв.

Вартість програмного забезпечення.

У цьому випадку вартість дорівнює собівартості плюс прибуток розробника (на практиці зазвичай становить 20-30% від собівартості), а також податок на додану вартість 20%. Для розрахунку можна використовувати наступну формулу , Де - Собівартість ПЗ, - Прибуток розробника, - Податок на додану вартість. Для замовника немає необхідності купувати програмне забезпечення, так як робота побудована практично вся на програмному забезпеченні замовника (робоче місце співробітника з необхідним ПЗ).

Прибуток розробника становить 6180,78 рублів

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

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

Вартість навчання персоналу організації. Розрахунок проводиться за такою формулою: , Де - Чисельність персоналу на навчання, - Вартість навчання однієї особи в день, - Час навчання. Передбачається, що в організації системою буде користуватися 1 співробітник. Час необхідний для навчання імовірно оцінюється в два робітники. Вартість навчання однієї особи в день 200 рублів. Разом виходить витрати на навчання персоналу 400 рублів.

Сумарні витрати для замовника представлені в таблиці 5.4.

Таблиця 5.4

Сумарні витрати для замовника і розробника, представлені у таблиці 5.5.

Таблиця 5.5

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

Таблиця 5.6

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

Таблиця 5.7

5.5 Ефективність впровадження для Замовника

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

Відповідно до плану графіку надання маркетингової звітності проведення анкетування ведеться по 15-ти видів анкет, які в свою чергу складаються приблизно з двох аркушів. Виходить, що одноразово витрачається 30 аркушів паперу. За даними минулого року було роздруковано близько 6500 анкет, з яких заповнений було 4350 анкет.

Таким чином, отримуємо, що було витрачено 2 * 6500 = 13000 аркушів паперу. Так як пачка паперу складається з 500 аркушів, то виходить, що на проведення анкетування в минулому році було витрачено 26 пачки паперу. Вартість однієї пачки паперу становить 120 рублів. У результаті отримуємо:

26 * 120 = 3120 рулів необхідно тільки на паперові ресурси

Також у витрати на тиражування анкет входить вартість друку, тиражування анкет відбувається на ксероксі, і вона включає в себе вартість використання ксерокса, а також витрати на фарбу. Один картридж коштує 1700 рулів, ресурсу якого вистачає на 2500 аркушів, виходить, що необхідно використовувати близько 3 картриджів. У результаті одержуємо, що витрати на фарбу складають: 3 * 1700 = 4420 рублів

Також необхідно врахувати витрати співробітника проводить маркетингове дослідження. Так як Москва надсилає шаблони анкет, то їх необхідно доопрацювати для подальшого тиражування. На редагування 15-ти шаблонів анкет у співробітника проводить маркетингове дослідження йде близько 15 годин. Після того як анкетування проведено, необхідно обробити всі отримані анкети, тобто внести дані в Exel. На даний вид робіт витрачається близько 240 годин на рік. На складання звіту по одному виду анкети йде один робочий день, що в підсумку становить 120 годин на всі види анкет. У результаті одержуємо, що співробітник витрачає 375 годин (45,85 робочих днів) на рік на проведення маркетингового дослідження за допомогою анкетування. Оклад працівника становить 5394 рубля.

Загальна сума витрат на проведення анкетування становить 20182 рубля.

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

Витративши на впровадження модуля 37484,72 рубля і економлячи на рік 20182 рублів, отримаємо, що період окупності складе:

37484,72 / 20 182 = 1 рік і 8 місяців.

5.6 Правові аспекти

Легальність інструментарію

При розробці Системи суворо дотримувалися всі умови ліцензійних угод продуктів Microsoft і супутніх компонентів. Витрати на комерційне використання інструментів розробника були пораховані вище.

Ліцензійна угода

Поняття ліцензійної угоди прийшло з Заходу. End user license agreement (EULA) - документ як правило існує в електронній формі, підписання якого є необхідною умовою використання програми на ЕОМ. EULA розробленої системи містить наступні пункти:

• загальні положення

• авторські права на програму

• права на розповсюдження програми

• захист відповідальності розробника (принцип "як є")

• захист цілісності і тиражування (копіювання, дизасемблювання, декомпілюванням і т.п.)

Захист авторських прав

При створенні Системи розробник керувався Федеральним Законом РФ від 23 вересня 1992 р. N 3523-I (в ред. Федерального закону від 24.12.2002 N 177-ФЗ) "Про правову охорону програм для електронних обчислювальних машин і баз даних". Стаття 4 Закону містить опис умов визнання авторського права. Згідно зі статтею, «для визнання і здійснення авторського права на програму для ЕОМ чи базу даних не потрібно депонування, реєстрації чи дотримання інших формальностей. Правовласник для сповіщення про свої права може, починаючи з першого випуску в світ програми для ЕОМ чи бази даних, використовувати знак охорони авторського права, що складається з трьох елементів:

літери С у колі або в круглих дужках;

найменування (імені) правоволодільця;

року першого випуску програми для ЕОМ чи бази даних у світ. "

Таким чином, у вікні «Про програму ...» з'явився наступний запис:

«Copyright ©, БФ МЕСИ, 2006р."

Висновки до розділу

Проаналізувавши всі вищевказані показники можна сказати про те, що проект є економічно ефективним.

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

• Розраховані витрати на розробку - 37484,72 рублів;

• Розраховано економічний ефект від впровадження - 20182 рублів;

• Термін окупності проекту складає 1 рік і 8 місяців.

Висновок

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

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

У ході реалізації даного проекту я отримав і закріпив теоретичні та практичні навички в області визначення вимог замовника, дослідження предметної області та об'єктно-орієнтованого підходу до розробки ПЗ. Я познайомився з визнаною світовою методологією MSF, і вся робота була пророблена згідно даної методології.

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

На стадії планування були більш детально вивчені бізнес процеси відділу маркетингу і в результаті чого були побудовані діаграми AS - IS і діаграми варіантів використання системи. У результаті дослідження діаграм UseCase були визначені модулі системи. Також були виділені сутності і побудована логічна модель даних, представлена ​​у вигляді діаграми "сутність-зв'язок".

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

На стадії реалізації в якості засобу розробки було прийнято рішення використовувати Microsoft Visual Studio. NET, за допомогою якого були розроблені модулі системи.

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

Список використаної літератури

1. Федеральний Закон РФ від 23.09.1992 р. № 3523-I (в редакції від 24.12.2002 № 177-ФЗ) Про правову охорону програм для електронних обчислювальних машин і баз даних.

2. Положення про маркетингової діяльності регіональних структур

3. Аналіз вимог і створення архітектури рішень на основі Microsoft. NET. Навчальний курс MCSD / Пер. з англ. - М.: Видавничо-торговий дім «Російська Редакція», 2004 .- 416 стор

4. Біляївський І.К. Маркетингове дослідження: інформація, аналіз, прогноз: Навчальний посібник. - М.: Фінанси і статистика, 2001

5. Буч Г. Рамбо. Д. Джекобсон А. Мова UML. Керівництво користувача: Пер. з англ. ДМК, 2000. - 432 с.

6. Вілдермьюс, Шон. Практичне використання ADO.NET. Доступ до даних в Internet. : Пер. з англ. - М.: видавничий дім "Вільямс", 2003. - 288 с.

7. Котлер Ф. Основи маркетингу / Пер. З англ. - М., Прогрес, 1999

8. Проектування економічних інформаційних систем: Підручник / Г.Н.Смірнова, А. А. Сорокін, Ю. Ф. Тельнов. - М: Фінанси і статистика, 2003. - 512стр.

9. Розробка Web-додатків на Microsoft Visual Basic. NET і Microsoft Visual C #. NET. Навчальний курс MCAD / MCSD / Пер. з англ. - М.: Видавничо-торговий дім «Російська Редакція», 2003. - 704стр.:

10. Сеппа Д. Microsoft ADO.NET / Пер. з англ. - М.: Видавничо-торговий дім «Російська Редакція», 2003 - - 640 стор

11. Теорія і практика побудови баз даних: Д. Кренке. - Пітер, 2003. - 800стр.

12. Royce, Winston W., "Managing the Development of Large Software Systems," Proceedings of IEEE Wescon (August 1970): pp 1-9

13. Barry Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol.21, No. 5 (May 1988): pp 61-72

14. Аналітична інформація http://www.citforum.ru/

15. Документи по MSF російською мовою http://www.microsoft.com/rus/msf

16. Маркетингові дослідження http://4p.net.ua/content/blogcategory/3/35/

17. МаркетПРО. Маркетингові дослідження в Росії і за кордоном. Http://www.marketpro.spb.ru

18. Офіційний сайт Microsoft Росія http://www.microsoft.com/rus/

19. Статті та аналітичні матеріали по ринку КІС http://erp.mctlab.ru/

Додаток 1