Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ

Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ

74

Введение

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

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

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

Заказчиком данной системы выступает отдел маркетинга БФ МЭСИ. Одной из решаемых задач отдела маркетинга является проведение маркетинговых исследований. В настоящее время при реализации этой задачи отделом маркетинга затрачиваются определенные ресурсы, как материальные, так и человеческие. Процесс проведения анкетирования от подготовки до непосредственного сбора анкет в БФ МЭСИ проводится вручную. Поэтому возникла необходимость в создании 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 в полном объеме используются преимущества многозадачности и параллельной обработки данных, такие как надежная работа с разделяемыми на уровне пользователей или приложений базами данных, разделение потока данных между серверами, параллельное создание индексов, ускорение сканирования баз данных в многопроцессорных системах, а также синхронизирует данные на всех серверах в кластере независимо от их местонахождения. Продукт переустанавливает и восстанавливает любую ветвь при сбое в кластере, не затрагивая остальные, легко конфигурируется для репликации и распределения потоков, обладает встроенной технологией клонирования серверов.

Страницы: 1, 2, 3