Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ (стр. 5 из 11)
Соединение OLAP кубов на различных серверах для анализа производительности. Поддерживается безопасный доступ к данным куба через Internet.
Параллельное DBCC - быстро и эффективно проверяет данные в базах данных с поддержкой многопроцессорной работы.
3.1 Общие сведения этапа планирования
Информации, собранной командой на этапе создания общей картины решения, обычно достаточно для начала работы над проектом. На этой стадии создается базовый документ общей картины и области действия решения. Ближе к концу этапа создания общей картины команда переходит к планированию модели процессов MSF. На этом этапе необходимо убедиться, что решаемая бизнес-проблема понимается полностью и команда в состоянии спроектировать адекватное решение. Кроме того, следует спланировать порядок разработки решения и оценить, достаточно ли для этого ресурсов.
На этапе планирования создается набор моделей и документов с перечнем требований — функциональная спецификация, или черновой план решения. Работа над ним начинается на этапе планирования.
На этапе планирования команда проекта продолжает работу, начатую на этапе создания общей картины решения, а именно: работает над предварительными требованиями, задачами, их последовательностью и профилями пользователей.
В результате должна быть выработана архитектура и дизайн решения, планы по его разработке и развертыванию и календарные графики выполнения задач и загрузки ресурсов. На этом этапе команда составляет как можно более четкую и ясную картину решения. Процесс планирования должен двигать проект вперед, однако многие команды на нем спотыкаются, слишком много времени уделяя планированию. Ключ к успеху — уловить тот момент, когда информации уже достаточно для дальнейшего движения вперед. При недостатке информации рискованно переходить к следующему этапу, с другой же стороны, избыток информации может стать причиной стагнации проекта
На этапе планирования разрабатываются три вида дизайна: концептуальный, логический и физический, причем эти процессы выполняются не параллельно. Они имеют «плавающие» начало и конец и зависят друг от друга.
Логический дизайн строится на основе концептуального, а физический — по результатам логического. Любые изменения концептуального дизайна отражаются на логическом дизайне и, в свою очередь, приводят к модификации физического дизайна.
3.2 Концептуальное проектирование
Концептуальный дизайн — это процесс сбора, анализа и определения приоритетов особенностей бизнеса и точек зрения пользователей на проблему и будущее решение, с последующим созданием высокоуровневого представления решения.
Во время сбора информации собираются предварительные требования. Очень важно, чтобы команда понимала разницу между различными категориями требований: пользовательскими, системными, процедурными и бизнес-требованиями.
Предварительные требования обычно формулируют на основе начальных интервью и другой информации, собранной на тот момент. По мере углубления понимания проблемы бизнеса предварительные требования расширяют и уточняют.
3.2.1 Описание модели бизнес процессов AS-IS
В настоящее время процесс сбора и обработки маркетинговых исследований методом анкетирования происходит следующим образом.
Рис. 3.1. Общий план анкетирования
Планирование проведения анкетирования:
На основании плана-графика предоставления маркетинговой отчетности составляется внутренний график проведения маркетинговых исследований. На данном этапе производится сбор всей необходимой информации для проведения анкетирования и составления анкет, который включает в себя формирование списка групп, в которых будет проводиться анкетирование, составление графика проведения анкетирования в соответствии с расписанием учебного процесса.
Рис. 3.2. Планирование проведения анкетирования
Создание анкеты
Назначается лицо, ответственное за создание анкеты, которое на основании шаблона формирует анкету, разрабатывает вопросы анкеты, а также перечень необходимых ответов. В дальнейшем сформированная форма анкеты тиражируется для дальнейшего распространения.
Рис. 3.2. Создание анкеты
Проведение анкетирования
Назначаются лица, ответственные за проведение анкетирования. Ими производится распространение анкет среди опрашиваемого контингента, а также объяснение по заполнению анкеты. Ими же производится сбор заполненных анкет.
Рис. 3.3. Проведение анкетирования
Обработка данных
Назначаются ответственные лица, которые просматривают собранные анкеты, анализируют их, и на основании проведенного анализа получают результаты. Анализ собранных данных осуществляется с использованием MicrosoftExcel. На основании собранных данных формируются отчеты маркетингового исследования, которые оформляются в соответствии с шаблоном.
Рис. 3.4. Обработка данных
Чтобы создать точный и пригодный к использованию концептуальный дизайн решения, необходим эффективный метод для представления и обсуждения решения с пользователями. Для этого создаются модели задач проекта. Один из способов моделирования таких задач и их последовательностей — построение вариантов использования системы.
3.2.2. Построение диаграммы вариантов использования
Вариант использования(Use case) специфицирует поведение системы или ее части и представляет собой описание множества последовательностей действий, выполняемых системой для того, чтобы актер мог получить определенный результат.
С помощью вариантов использования можно описать поведение разрабатываемой системы, не определяя ее реализацию. Таким образом, они позволяют достичь взаимопонимания между разработчиками, экспертами и конечными пользователями продукта. Кроме того, варианты использования помогают проверить архитектуру системы в процессе ее разработки. Реализуются они кооперациями.
Хорошо структурированные варианты использования описывают только существенное поведение системы или подсистемы и не являются ни слишком общими, ни слишком специфическими.
Важнейшая особенность разработки вариантов использования состоит в том, что вы не специфицируете, как они будут реализованы. Варианты использования специфицируют желаемое поведение, но ничего не говорят о том, как его достичь. И, что очень важно, это позволяет вам как эксперту или конечному пользователю общаться с разработчиками, конструирующими систему в соответствии с требованиями, не углубляясь в детали реализации.
В UML поведение моделируется с помощью прецедентов, специфируемых в отрыве от реализации. Прецедент - это описание множества последовательностей действий (включая их варианты), которые выполняются системой для того, чтобы актер получил результат, имеющий для него определенное значение. Это определение включает в себя несколько важных пунктов.
Прецедент описывает множество последовательностей, каждая из которых представляет взаимодействие сущностей, находящихся вне системы (ее актеров), с системой как таковой и ее ключевыми абстракциями. Такие взаимодействия являются в действительности функциями уровня системы, которыми вы пользуетесь для визуализации, специфицирования, конструирования и документирования ее желаемого поведения на этапах сбора и анализа требований. Прецедент представляет функциональные требования к системе в целом.
Прецеденты предполагают взаимодействие актеров и системы. Актер представляет собой логически связанное множество ролей, которые играют пользователи прецедентов во время взаимодействия с ними. Актерами могут быть как люди, так и автоматизированные системы.
Развитие прецедентов может осуществляться по-разному. В любой хорошо продуманной системе существуют прецеденты, которые либо являются специализированными версиями других, более общих, либо входят в состав прочих прецедентов, либо расширяют их поведение. Общее поведение множества прецедентов, допускающее повторное применение, можно выделить, организуя их в соответствии с тремя описанными видами отношений.
Всякий прецедент должен выполнять некоторый объем работы. С точки зрения данного актера, прецедент делает нечто представляющее для него определенную ценность, например, вычисляет результат, создает новый объект или изменяет состояние другого объекта.
Прецеденты могут быть применены ко всей системе или к ее части, в том числе к подсистемам или даже к отдельным классам и интерфейсам. В любом случае прецеденты не только представляют желаемое поведение этих элементов, но могут быть использованы как основа для их тестирования на различных этапах разработки.
На следующей диаграмме описывается процесс создания анкеты:
Рис. 3.5. Диаграмма вариантов использования Создать анкеты
