На этапе планирования разрабатываются три вида дизайна: концептуальный, логический и физический, причем эти процессы выполняются не параллельно. Они имеют «плавающие» начало и конец и зависят друг от друга.
Логический дизайн строится на основе концептуального, а физический -- по результатам логического. Любые изменения концептуального дизайна отражаются на логическом дизайне и, в свою очередь, приводят к модификации физического дизайна.
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) обычно считают человека, место, элемент или понятие, которое определяет данные или о котором данные собираются и хранятся. Атрибут -- это характеристика, представляющая собой дополнительное определение и описание свойств экземпляра сущности. У сущности обычно несколько атрибутов.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
