Размещено на http://www.allbest.ru

СОДЕРЖАНИЕ

Введение

Глава 1. Современное состояние проблемы планирования работ при создании сайтов

1.1 Описание деятельности веб-студии по созданию сайтов

1.2 Анализ современных систем управления задачами

1.3 Постановка задачи разработки системы планирования выполнения заказов на разработку сайтов

Выводы по Главе 1

Глава 2. Формирование технических требований к системе планирования выполнения заказов на разработку сайтов

2.1 Обоснование выбора метода функционального моделирования для формирования технических требований к проектируемой системе

2.2 Моделирование бизнес-процессов деятельности организации по разработке сайтов

2.3 Технические требования к проектируемой системе

Выводы по Главе 2

Глава 3. Проектирование системы планирования

3.1 Обоснование выбора средств проектирования

3.2 Проектирование логической модели системы

3.3 Разработка логической и физической моделей базы данных

3.4 Оценка эффективности спроектированной системы планирования

Выводы по Главе 3

Заключение

Список использованных источников



ВВЕДЕНИЕ

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

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

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

Особое место занимают информационные системы по работе с заказчиками. Как и любые крупные организации, работающие в этой сфере, так и веб-студии также нуждаются в автоматизации процесса выполнения заказов.

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

Для достижения поставленной цели необходимо выполнить следующие задачи:

- провести анализ процессов разработки сайта;

- выявить особенности процесса создания сайта;

- проанализировать рынок на наличие подобных программных продуктов;

- выявить преимущества и недостатки существующих систем управления задачами;

- разработать требования к проектируемой системе;

- изучить доступные средства проектирования и выбрать наиболее подходящие для решения задачи;

- разработать логическую модель системы с учетом разработанных требований и недостатков аналогичных систем;

- провести моделирование данных системы с помощью разработки логической и физической моделей базы данных.

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

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



ГЛАВА 1. СОВРЕМЕННОЕ СОСТОЯНИЕ ПРОБЛЕМЫ ПЛАНИРОВАНИЯ РАБОТ ПРИ СОЗДАНИИ САЙТОВ

1.1 Описание деятельности веб-студии по созданию сайтов

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

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

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

Также у некоторых студий имеется опыт использования систем отслеживания ошибок - bug tracking system, сервисов для контроля выполнения задач - task tracking и систем управления проектами. При выборе системы управления проектами и задачами, которая бы отвечала всем потребностям веб-студии, необходимо учесть, что внутри данной организации происходит довольно быстрая и напряженная работа над несколькими проектами сразу, при этом многие из которых находятся на разных этапах выполнения. Сотрудникам приходится выставлять жесткие приоритеты задачам и в то же время помнить о незначительных деталях, которых появляется огромное количество в процессах разработки и поддержки сайтов.

Любое производство представляет собой совокупность взаимосвязанных технологических операций, выполняемых производственным персоналом. В производстве сайтов участвуют следующие сотрудники веб-студии:

- менеджер по продажам услуг

- исполнительный менеджер

- контент-менеджер

- дизайнер

- верстальщик

- программист

- тестировщик

Таким образом, работа веб-студии характеризуется немалым количеством реализуемых одновременно проектов и небольшим количеством сотрудников. Успех предприятия в первую очередь зависит от ключевой фигуры - менеджера, курирующего ведение проекта, главная задача которого следить за коммуникацией всех участников процесса. Современные веб-студии для повышения качества выполненных проектов стремятся привлекать к работе высококвалифицированных специалистов, среди которых могут быть фрилансеры и/или сотрудники, работающие вне офиса, т.е. удаленно. Эта особенность организации работ в веб-студиях приводит к определенным сложностям в реализации проектов. К ним относятся:

- занятость сотрудника в нескольких проектах

- неумение многих представителей фриланса управлять временем и устанавливать приоритеты задачам в рамках даже одного проекта

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

Первым фактором, который определяет потенциальный риск возникновения проблем в работе, является ведение сразу нескольких проектов, находящихся на разных стадиях реализации. Вторым фактором является наличие большого объема информации по каждому проекту, подлежащей структурированию. Например, Техническое задание на сайт, Бриф на дизайн сайта, комментарии и правки заказчика, многочисленные данные по каждому заказчику (логины, пароли, учетные записи хостингов и т.д.). Многие компании не учитывают эту особенность в своей работе и хранят неструктурированную информацию в электронной почте, просматривая по мере необходимости переписку с клиентом, чем совершают роковую ошибку, ведь база почтового клиента, особенно бесплатной корпоративной почты, является ненадежным хранилищем данных, можно безвозвратно потерять часть важной переписки.

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

Этап 1: Продажа

- обращение клиента в компанию по телефону или лично

- ознакомление клиента с принципами создания сайта

- определение целей разработки сайта

- проведение маркетинговых исследований

- обсуждение концепции будущего сайта

- подготовка плана работ

- составление, согласование и подписание Договора

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

Этап 2: Формирование технических требований

- формирование требований по дизайну

- сбор исходных материалов

- заполнение, согласование с клиентом, подписание Брифа

- формирование требований к структуре, контентному наполнению, сервисам сайта

- составление, согласование с клиентом, подписание Технического задания

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

Этап 3: Разработка дизайна

- разработка дизайн-концепции главной страницы сайта

- презентация, доработка и согласование макета главной страницы с заказчиком

- разработка макетов внутренних страниц (категории, товары, услуги, контакты и т.п.)

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

- разработка дизайна экранных форм (каталог, личный кабинет, корзина)

- презентация, доработка и согласование каждой из экранных форм

На данном этапе заказчиком утверждается дизайн-концепция сайта на примере главной страницы. Каждый шаг разработки макета выполняется в соответствии с составленными Техническим заданием и Брифом. Если планировалось создание мобильной версии сайта, то на этапе разработки дизайна каждый макет переделывается в форму мобильной версии. Как описывалось выше, очень часто возникают проблемы со сбором исходных материалов для сайта. В связи с этим на макете допустимо отсутствие некоторого наполнения: вместо текстовой информации вставляется демо-текст, а вместо фотографий - картинки. Тем не менее, должны быть прорисованы все элементы дизайна. [1]

Этап 4: Верстка

- реализация созданного дизайн-макета главной страницы, типовой внутренней страницы, экранных форм

- размещение графических элементов

- оптимизация кода

- презентация заказчику, доработка замечаний и утверждение верстки

Верстка является чисто технической работой, результат которой зависит от профессиональных навыков верстальщика. Заказчиком утверждается конечный результат верстки. Также, если планировалось создание мобильной версии сайта, то на этапе верстки происходит реализация макета в форме мобильной версии.

Этап 5: Программирование

- разработка базового функционала (новостная лента, поиск, каталог, корзина, обратная связь и т.п.)

- разработка дополнительных компонентов и модулей (расширенные формы регистрации и авторизации пользователей, защита материалов от копирования и т.п.)

На данном этапе также дорабатывается функционал сайта в соответствии с дополнительными требованиями, которые также определяются Техническим заданием.

Этап 6: Тестирование

- внутреннее тестирование

- тестирование заказчиком

- утверждение программной части заказчиком

Этап отражает совместное тестирование продукта разработчиком и заказчиком и исправление ошибок.

Этап 7: Закрытие проекта

- перенос сайта на рабочий сервер (выбор доменного имени и размещение на хостинге)

- согласование результата работ с заказчиком

- обучение заказчика работе с системой управления сайта

- выставление и оплата счета

- закрытие документации

Размещение проектов на хостинге заказчика, как не удивительно, является одной из основных проблем в создании сайта (домен не функционирует с хостингом, заказчик не помнит пароли, не работает система управления). Далее возможно продвижение и реклама сайта в интернете для привлечения на него посетителей. Это достигается при помощи продвижения сайта в поисковых системах и каталогах, контекстной или баннерной рекламы и других методов.

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

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

1.2 Анализ современных систем управления задачами

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

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

- Битрикс24

- Мегаплан

- Pyrus

- iQ300

- WorkFlow Soft

- Asana

- Wrike

- Basecamp

Рассмотрим преимущества и возможные недостатки предложенных программных продуктов.

Таблица 1

Сводный анализ рассмотренных программных решений

Система	Преимущества	Недостатки
Битрикс24	Внутри задачи чек-лист с подзадачами, возможно управление задачами прямо на диаграмме Гантта	Излишняя функциональность
Мегаплан	Модуль управления проектами и постановки задач учитывает мельчайшие детали, наличие иерархии и вложенности задач	Излишняя функциональность, отсутствие чек-листов
Pyrus	Возможности интеграции с множеством сервисов, создание повторяющихся задач	Отсутствие чек-листов, недостаточно четкая классификация задач, нет полей для комментариев к участникам процесса
iQ300	Низкая стоимость владения, наличие чек-листов, возможность создания рабочих групп	Иногда неясное поведение интерфейса, чек-листы не отображаются в поле проекта (доступны только через задачу)
WorkFlow Soft	Конструктор шаблонов и маршрутов выполнения задачи, понятный интерфейс	Высокая стоимость владения, отсутствие чек-листов, минимальная стандартная форма создания задачи
Asana	Наличие чек-листов, понятный интерфейс, создание нескольких рабочих разделов, наличие иерархии и вложенности задач	Английская локализация, в бесплатной версии открытое ведение группового проекта
Wrike	Наличие чек-листов, возможность создания рабочих групп, наличие иерархии и вложенности задач, дерево задач, возможно управление задачами прямо на диаграмме Гантта	Высокая стоимость владения, на некоторых тарифах недоступны подзадачи
Basecamp	To-do лист, понятный интерфейс, форумы для обсуждения задач и проектов, закрытое ведение группового проекта	Минимальная стандартная форма создания задачи, нельзя сформировать отчет о выполненных задачах

Важно отметить, что выявленные недостатки в зависимости от требований, предъявляемых пользователями к системе, могут быть различной степени критичности. Например, если студия начинает свою работу как небольшая компания и планирует в дальнейшем расширять спектр предлагаемых услуг, то для этой цели целесообразно будет приобретать сразу комплексные решения, такие как Битрикс24 или Мегаплан. В таких системах функции управления проектами реализованы в отдельной подсистеме. С другой стороны, если не планируется расширение портфеля услуг, например, быть веб-студией, специализирующейся только на разработке сайтов, то стоит пользоваться подходящим инструментом, отвечающим основным требованиям.

Программа Pyrus отличается возможностями интеграции со многими сервисами и наличием API (Application Programming Interface). Нужным функционалом для разработки сайтов является создание повторяющихся задач, потому что в работе веб-студии достаточно часто встречаются рутинные задачи. К минусам этой системы можно отнести отсутствие чек-листа, также как и у программных решений Мегаплан и WorkFlow Soft. Наличие простейшего чек-листа в системе поможет контролировать этапы выполнения проекта или список дел для сотрудника.

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

Существенным недостатком систем WorkFlow Soft и Wrike является достаточно высокая стоимость владения. Для всех представленных систем были рассмотрены тарифы для использования в течение 1 года командой из 10 человек. Самой низкой по цене оказалась iQ300.

Система WorkFlow Soft отличается тем, что, фактически, позволяет моделировать бизнес-процессы. Она подойдет для тех, кому интересна логическая связанность задач, а также построение маршрутов выполнения задачи (от формирования документации до разработки готового сайта). Но она обладает минимальным функционалом для формы создания задачи, как и Basecamp.

Продукт Basecamp позволяет закрытое ведение проекта, когда видят и вносят изменения только его участники. В отличие от него, недостатком бесплатной версии Asana является видимость и доступность группового проекта всем желающим, у кого есть URL адрес. К субъективному недостатку в Asana можно отнести невозможность просмотреть все задачи с подзадачами, когда в системе Wrike настраивается отображение всего дерева задач.

Немного выходит за рамки простой системы управления проектами Basecamp, позиционируя себя еще и как корпоративный портал. На рабочем столе помимо панелей заметок, опросов и дел можно закрепить чат для формального и неформального общения с командами, которые создаются отдельно. Задачи здесь отображаются в виде простого to-do листа. Система хорошо подходит для небольших команд, однако в ней отсутствует возможность автоматического формирования отчета о выполненных задачах.

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

1.3 Постановка задачи разработки системы планирования выполнения заказов на разработку сайтов

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

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

С помощью системы пользователи-исполнители должны видеть приоритеты всех поставленных задач и четко знать, какой задачей следует заниматься.

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

Для клиентов система должна отображать статус заказа на разработку сайта и время, оставшееся до завершения определенного этапа выполняемого проекта.

Также система должна уметь учитывать проекты и запоминать всю ту важную информацию, которая хранится на листочках, в блокнотах и в электронной почте. Для упрощения работы с системой необходимы максимально простые меню и интерфейс. Кроме того, следует предусмотреть распределение задач в зависимости от возможностей исполнителей, требуемого времени на задачу и ее сложности. Многие процессы, такие как постановка задачи, выбор задачи, формирование отчетности могут быть автоматизированы, что позволит оптимизировать работу в целом.

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

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

Выводы по Главе 1

В первой главе работы получены следующие результаты:

1. Описаны этапы разработки сайтов в веб-студиях и определены проблемы, связанные с планированием работ по разработке сайтов.

2. Проведен сводный анализ существующих на современном рынке систем управления задачами для веб-студий, показаны их преимущества и недостатки.

3. Сформулирована постановка задачи и общие требования к системе, а также определены ее цели.



ГЛАВА 2. ФОРМИРОВАНИЕ ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ К СИСТЕМЕ ПЛАНИРОВАНИЯ ВЫПОЛНЕНИЯ ЗАКАЗОВ НА РАЗРАБОТКУ САЙТОВ

2.1 Обоснование выбора метода функционального моделирования для формирования технических требований к проектируемой системе

Процесс создания информационной системы состоит из ряда этапов, каждый из которых имеет свои временные рамки и характеризуется результатами выполнения работ. Можно выделить следующие этапы создания информационной системы: разработка требований к системе, проектирование системы, реализация, тестирование, внедрение, эксплуатация и сопровождение.

Методология проектирования ИС описывает жизненный цикл ИС, позволяя таким образом спланировать и организовать процесс разработки. В настоящее время существует несколько моделей жизненного цикла программного обеспечения ИС. На Рис. 1 изображена поэтапная модель с промежуточным контролем.

Рис. 1. Поэтапная модель с промежуточным контролем

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

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

Для проведения моделирования чаще всего используются графические методы, так как они отличаются простотой представления информации о компонентах системы и позволяют обеспечить структурную декомпозицию процессов с различной степенью детализации. Главное требование, предъявляемое к графическому моделированию - простота.

Выделяют функционально-ориентированные и объектно-ориентированные методологии структурного моделирования в зависимости от представлений о моделируемой организации. Каждый из подходов к отображению организационной структуры обладает своими преимуществами. Представление организации в виде набора взаимодействующих объектов (производственных единиц) используется в объектных методиках. А представление в виде набора функций, который преобразует входной поток информации в выходной при потреблении определенных ресурсов, используется в функциональных методиках, среди которых наиболее известной является IDEF. Такой подход интуитивно лучше понимается исполнителями.

Функциональное моделирование предоставляет возможность четко отделить сами данные от функций, т.е. от методов их обработки. Такой подход подробно отобразит деятельность организации по разработке сайтов, поэтому для графического моделирования деятельности веб-студии была использована функциональная методика IDEF0. Наглядность этой методики позволяет понять модель даже лицам, не принимавшим участия в ее создании, а также это наиболее удобный язык моделирования бизнес-процессов.

Методология IDEF0 (Function Modeling) используется для создания функциональной схемы исследуемой системы, которая представляет собой структурированное отображение функций системы, а также описывает информацию и объекты, связывающих эти функции. Понятия функционального блока (Activity Box), интерфейсной дуги (Arrow) и декомпозиции (Decomposition) являются основными в данной методологии.

Функциональный блок используется для представления одной конкретной функции в рамках моделируемой системы. На диаграммах он изображается в виде прямоугольника и имеет название в глагольном наклонении по требованиям стандарта IDEF0 (рис. 2.). У каждой из его четырех сторон есть свое определенное значение:

- «Управление» (Control) - верхняя сторона

- «Вход» (Input) - левая сторона

- «Выход» (Output) - правая сторона

- «Механизм» (Mechanism) - нижняя сторона

Рис.2. Функциональный блок

Интерфейсная дуга используется для отображения компоненты системы, обрабатываемой функциональным блоком, и в той или иной степени определяет процессы, которые происходят в системе. Название интерфейсной дуги («входящая», «исходящая» или «управляющая») зависит от стороны функционального блока, к которой она подходит. По требованиям стандарта IDEF0 любой функциональный блок должен иметь хотя бы одну управляющую и одну исходящую интерфейсную дугу.

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

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

2.2 Моделирование бизнес-процессов деятельности организации по разработке сайтов

Моделирование бизнес-процессов выполняется с помощью CASE-средств (Computer Aided Software Engineering). К ним относятся AllFusion Process Modeler (бывший BPWin), Silverrun, Oracle Designer, Rational Rose и др. Графическое моделирование деятельности организации по разработке сайтов было проведено с помощью CASE-средства - AllFusion Process Modeler.

AllFusion Process Modeler - мощный инструмент моделирования, который применяется для описания, анализа, документирования и реорганизации бизнес-процессов, имеет интуитивно понятный и достаточно простой интерфейс. Он позволяет эффективно манипулировать моделями, а также обладает широким набором средств документирования.

Ниже представлены контекстная диаграмма и детализация бизнес-процессов разработки сайтов, а также их описание в таблицах.

Таблица 2

Описание диаграммы А-0 «Выполнить заказ на разработку сайта»

Бизнес-функция	Вход	Выход	Управление	Механизм
Выполнить заказ на разработку сайта	1. Заявка	1. Сайт 2. Договор 3. Счет	1. Требования заказчика 2. Регламент веб-разработки 3. Требования хостинговых провайдеров	1. Рабочая группа 2. Инструментальные средства разработки

Рис. 3. Диаграмма А-0 «Выполнить заказ на разработку сайта»



Таблица 3

Описание диаграммы А-0 «Выполнить заказ на разработку сайта»

Бизнес-функция	Вход	Выход	Управление	Механизм
Обработать заявку клиента и подготовить план работ	1. Заявка	1. Договор 2. Стратегия работы	1. Требования заказчика	1. Рабочая группа: менеджер по продажам услуг
Спроектировать общую концепцию продукта	1. Стратегия работы	1. Бриф на дизайн сайта 2. Техническое задание 3. Информационные материалы заказчика	1. Регламент веб-разработки 2. Требования заказчика	1. Рабочая группа: исполнительный менеджер, контент-менеджер
Разработать дизайн сайта	1. Бриф на дизайн сайта 2. Техническое задание3. Информационные материалы заказчика	1. Дизайн-макеты главной страницы, внутренних страниц и экранных форм сайта	1. Регламент веб-разработки 2. Требования заказчика	1. Рабочая группа: исполнительный менеджер, дизайнер 2. Инструментальные средства разработки
Сверстать дизайн-макеты сайта	1. Дизайн-макеты главной страницы, внутренних страниц и экранных форм сайта 2. Техническое задание	1. HTML-шаблоны сайта	1. Регламент веб-разработки 2. Требования заказчика	1. Рабочая группа: исполнительный менеджер, верстальщик 2. Инструментальные средства разработки
Разработать дополнительный функционал	1. HTML-шаблоны сайта 2. Техническое задание	1. Страницы веб-сайта с дополнительным функционалом	1. Регламент веб-разработки 2. Требования заказчика	1. Рабочая группа: исполнительный менеджер, программист 2. Инструментальные средства разработки
Протестировать веб-сайт	1. Страницы веб-сайта с дополнительным функционалом	1. Протестированный веб-сайт	1. Регламент веб-разработки	1. Рабочая группа: исполнительный менеджер, тестировщик 2. Инструментальные средства разработки
Закрыть проект	1. Протестированный веб-сайт	1. Сайт 2. Счет	1. Требования хостинговых провайдеров	1. Рабочая группа: исполнительный менеджер

Рис. 4. Диаграмма А-0 «Выполнить заказ на разработку сайта»

Таблица 4

Описание диаграммы А1 «Обработать заявку клиента и подготовить план работ»

Бизнес-функция	Вход	Выход	Управление	Механизм
Обработать заявку клиента	Заявка	1. Данные заявки на разработку сайта 2. Сформированные цели разработки сайта	Требования заказчика	Рабочая группа: менеджер по продажам услуг
Провести исследования конкурентов	Сформированные цели разработки сайта	Результаты исследований и обсуждения с клиентом		Рабочая группа: менеджер по продажам услуг
Подготовить оптимальный план работ	1. Данные заявки на разработку сайта 2. Результаты исследований и обсуждения с клиентом	Стратегия работы	Требования заказчика	Рабочая группа: менеджер по продажам услуг
Составить договор с клиентом	Данные заявки на разработку сайта	Договор	Требования заказчика	Рабочая группа: менеджер по продажам услуг

Рис. 5. Диаграмма А1 «Обработать заявку клиента и подготовить план работ»

Таблица 5

Описание диаграммы А2 «Спроектировать общую концепцию продукта»

Бизнес-функция	Вход	Выход	Управление	Механизм
Формирование требований к сайту	Стратегия работы	1. Список требований по дизайну сайта 2. Список требований к структуре, контенту, сервисам сайта	1. Требования заказчика 2. Регламент веб-разработки	Рабочая группа: исполнительный менеджер
Составить Бриф на дизайн сайта	Список требований по дизайну сайта	Бриф на дизайн сайта	1. Требования заказчика 2. Регламент веб-разработки	Рабочая группа: исполнительный менеджер
Составить Техническое задание	Список требований к структуре, контенту, сервисам сайта	Техническое задание	1. Требования заказчика 2. Регламент веб-разработки	Рабочая группа: исполнительный менеджер
Собрать исходные материалы	Стратегия работы	Информационные материалы заказчика		Рабочая группа: контент-менеджер

Рис. 6. Диаграмма А2 «Спроектировать общую концепцию продукта»



Таблица 6

Описание диаграммы А7 «Закрыть проект»

Бизнес-функция	Вход	Выход	Управление	Механизм
Перенести сайт на рабочий сервер	Протестированный веб-сайт	1. Сайт 2. Информация о выполненных работах	Требования хостинговых провайдеров	Рабочая группа: исполнительный менеджер
Выставить и оплатить счет	Информация о выполненных работах	Счет		Рабочая группа: исполнительный менеджер

Рис. 7. Диаграмма А7 «Закрыть проект»

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



2.3 Технические требования к проектируемой системе

Требования к системе в целом:

1. Система должна представлять собой веб-приложение;

2. Должно осуществляться быстрое развертывание системы;

3. В состав системы должна входить подсистема хранения данных;

4. Система должна предусматривать возможность дальнейшей модернизации;

5. Для эксплуатации системы должны быть определены следующие роли:

1) Администратор системы. Основные обязанности администратора - обеспечение корректного функционирования системы. Администратор должен обладать опытом работы с персональным компьютером на уровне квалифицированного пользователя.

2) Оператор системы. Основные обязанности оператора - работа в системе. Требования по специальным навыкам и знаниям оператора не предъявляются.

6. Система должна обеспечивать восстановление своих функций при возникновении внештатных ситуаций;

7. Система должна иметь понятный и удобный визуальный графический интерфейс, соответствующий современным эргономическим требованиям, все элементы интерфейса должны быть на русском языке;

8. Для защиты информации от несанкционированного доступа система должна обеспечивать идентификацию пользователей, разграничение доступа по уровням задач для пользователей, использование «слепых» паролей (отображение на экране символов одного типа при наборе пароля).

Требования к функциям (задачам), выполняемым системой:

1. Для пользователей система должна обеспечивать:

1) доступ через браузер;

2) регистрацию пользователей при первом входе в систему;

3) авторизацию пользователей с использованием логина и пароля при последующем входе в систему.

2. Система должна поддерживать выполнение следующих функций для организации формы проекта по разработке сайта:

1) создание и просмотр проекта;

2) отображение названия проекта;

3) возможность создания нескольких проектов;

4) организация вложенных иерархий (разделение проекта на задачи и подзадачи);

5) реализация формы задачи внутри проекта с учетом особенностей работы веб-студий;

6) отображение промежуточных этапов проекта.

3. Система должна поддерживать выполнение следующих функций для организации формы задачи в проекте:

1) создание и просмотр задач и подзадач в проекте;

2) автоматическое генерирование простого чек-листа при создании задачи, в котором должны появляться зачеркнутые пункты по мере выполнения подзадач с указанием следующих полей:

a. точное время закрытия подзадачи;

b. дата закрытия подзадачи;

c. закрывший сотрудник.

3) отображение названия задачи;

4) отображение краткого описания задачи;

5) установка дедлайна для задачи (крайнего срока выполнения);

6) установка статуса для задачи (например, «назначена», «ожидает выполнения», «выполняется», «закрыта»);

7) установка приоритета для задачи;

8) осуществление сортировки задач по приоритетам;

9) отображение очереди задач;

10) перемещение задач, ожидающих выполнения, в очередь задач (определение места в очереди в соответствии с приоритетом и дедлайном выполнения задачи);

11) возможность назначения и изменения исполнителя для задачи;

12) установка сценария для задачи, в зависимости от типа производимых работ;

13) отображение дополнительных полей для задачи, в зависимости от установленного сценария;

14) возможность создания комментариев к задаче зарегистрированными пользователями.

Выводы по Главе 2

Во второй главе работы получены следующие результаты:

1. Произведен обоснованный выбор метода функционального моделирования для разработки технических требований к системе.

2. Произведено функциональное моделирование бизнес-процессов деятельности веб-студии по созданию сайта.

3. Сформулированы технические требования к системе планирования выполнения заказов на разработку сайтов в соответствии с разработанными моделями бизнес-процессов.



ГЛАВА 3. ПРОЕКТИРОВАНИЕ СИСТЕМЫ ПЛАНИРОВАНИЯ

3.1 Обоснование выбора средств проектирования

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

В настоящее время существует довольно много инструментальных средств и технологий, с помощью которых реализуется проект ИС. Важное место среди них занимает унифицированный язык объектно-ориентированного моделирования UML (Unified Modeling Language) - стандартная нотация визуального моделирования программных систем, которая была принята консорциумом OMG (Object Managing Group) в 1997 году.

Преимущества UML в том, что он является достаточно гибким для отражения и настройки специфики деятельности разработчиков, и с помощью него многие объектно-ориентированные CASE-продукты поддерживают жизненный цикл ИС. Он предоставляет возможность моделирования этапов жизненного цикла информационной системы с помощью совокупности диаграмм, а также позволяет детально описать архитектуру системы.

Для объектно-ориентированного моделирования на языке UML был использован программный продукт Enterprise Architect. Enterprise Architect - это программа для UML-моделирования и проектирования информационных систем, поддерживает все виды диаграмм UML, имеет дружественный интерфейс, предоставляет возможность многопользовательской работы, позволяет моделировать базы данных и имеет еще множество возможностей.

С помощью инструментального средства Enterprise Architect были созданы диаграмма вариантов использования, диаграммы последовательности и диаграмма классов.

Информационная база является одной из основных частей информационного обеспечения системы. Она представляется как совокупность данных, которые организованы определенным образом и хранятся в виде файлов в памяти вычислительной системы, которые позволяют удовлетворять потребности управленческих процессов и решаемых задач в информации. Моделирование данных используется для разработки базы данных. [4]

ERD-диаграммы (диаграммы «сущность-связь») являются распространенным средством моделирования данных [2] и обеспечивают стандартный способ определения данных и отношений между ними. С их помощью выполняется детализация хранилищ данных системы.

Метод IDEF1 является распространенным методом построения ERD-диаграмм, с помощью него можно построить модель данных, которая будет эквивалентна реляционной модели в третьей нормальной форме. Его усовершенствованная версия - метод IDEF1X, который был разработан с учетом простоты для изучения и возможности автоматизации. IDEF1X-диаграммы используются в CASE-средстве ERwin, с помощью которого и были построены логическая и физическая модели базы данных.

Erwin (AllFusion ERwin Data Modeler) - программный продукт для проектирования, создания, документирования и сопровождения баз данных, хранилищ и витрин данных. С помощью ERwin можно наглядно отобразить сложные структуры данных, он имеет достаточно простой и интуитивно понятный интерфейс.

Моделирование данных начинается, как правило, с создания логической модели. В ERwin после разработки логической модели можно сгенерировать необходимую физическую модель в зависимости от выбора системы управления базы данных, поддерживаемой ERwin. Также, после создания физической модели можно сгенерировать SQL-скрипт для конкретной системы управления базами данных.

В качестве средства для управления базами данных будет использовано Microsoft SQl Server. Microsoft SQl Server - это система управления реляционными базами данных, разработана корпорацией Microsoft, используется для работы, как с персональными, так и с крупными базами данных масштаба предприятия. Ее преимуществами являются: достаточно простое управление системой; широкие возможности для интеграции и синхронизации данных; наличие облачного сервиса для хранения, обработки и резервного копирования данных; расширенные функции безопасности. Также есть возможность загрузки бесплатных версий SQL Server.

3.2 Проектирование логической модели системы

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

Организационная диаграмма позволит разобраться с текущей ситуацией и наглядно отобразить организационную структуру производственного персонала веб-студии для дальнейшего определения функций подразделений и построения логической модели системы. Организационная диаграмма представлена на Рис. 8.



Рис. 8. Организационная структура производственного персонала веб-студии

В соответствии с данной диаграммой создадим логическую модель системы на Унифицированном языке моделирования (UML) для понимания работы системы в целом. Логическая модель информационной системы описывает требования к системе в виде модели и описания системных прецедентов.

С помощью программного продукта Enterprise Architect построим диаграмму вариантов использования, диаграммы последовательности и диаграмму классов.

Диаграмма вариантов использования (диаграмма прецедентов, use case diagram) предназначена для построения обобщенной модели функционирования системы в окружающей среде.

Основные элементы модели прецедентов:

- Актер (actor) - элемент модели, который обозначает роли пользователя системы, взаимодействующий с определенной сущностью;

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

В модели могут быть установлены следующие связи между прецедентами:

- включение (include) отображает взаимосвязи нескольких вариантов использования, основной (базовый) из которых использует функциональное поведение включаемых вариантов;

- расширение (extend) отображает взаимосвязь между базовым вариантом использования и вариантами, которые являются его специальными случаями;

- обобщение (generalization) отображает общность ролей.

Диаграмма вариантов использования изображена на Рис.9.

Рис. 9. Диаграмма вариантов использования

Диаграмма последовательности (sequence diagram) предназначена для отображения проявлений взаимодействия объектов, упорядоченных по времени.

Основные элементы диаграммы данного типа:

- объекты, которые выполняют действия;

- вертикальные линии (lifeline), которые моделируют течение времени;

- стрелки, которые определяют совершаемые действия.

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

На Рис. 10 изображена диаграмма последовательности для прецедента «регистрация в системе».

Рис. 10. Прецедент «регистрация в системе»

На Рис. 11 изображена диаграмма последовательности для прецедента «авторизация в системе».



Рис. 11. Прецедент «авторизация в системе»

На Рис. 12 изображена диаграмма последовательности для прецедента «обработать заказ».

Рис. 12. Прецедент «обработать заказ»



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

На основе построенных диаграмм можно создать диаграмму классов. Диаграмма классов (class diagram) представляет собой логическую модель базовой структуры системы, предназначена для отображения статической структуры и связей между элементами системы с использованием терминологии классов объектно-ориентированного программирования.

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

Могут быть установлены следующие отношения между классами:

- зависимость - описание отношений использования между классами;

- ассоциация - описание структурных отношений между объектами классов;

- обобщение - связывание обобщенных классов со специализированными классами.

Диаграмма классов проектируемой системы изображена на Рис. 13.



Рис. 13. Диаграмма классов

Созданная логическая модель проектируемой системы позволила структурировать требования к функциональности и элементам системы, а также подробно описать ее состав и функции в соответствии с разработанными моделями бизнес-процессов.

На основе разработанной логической модели проведем прототипирование интерфейса системы (Рис. 14 и Рис. 15).



Рис. 14. Интерфейс задачи «Создание сайта»

Задача «Создание сайта» включает в себя 4 этапа: разработка дизайна, верстка, программирование и тестирование. Для каждого этапа дается ссылка на Техническое задание, прописываются исполнители, указываются дата дедлайна и пожелания клиента. Как и в любой другой задаче, внутри каждого этапа можно создать описание задачи, прикрепить файлы, указать приоритет и статус.

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

Рис. 15. Интерфейс чек-листа для сотрудника

3.3 Разработка логической и физической моделей базы данных

Базовыми понятиями ERD-диаграмм являются сущность (Entity), связь (Relationship) и атрибут (Attribute).

Сущность - это множество экземпляров реальных или абстрактных объектов, которые обладают общими характеристиками или атрибутами. Любая сущность должна быть уникально идентифицирована, а ее имя должно отражать тип или класс объекта.

Поименованная ассоциация между двумя сущностями называется связью и означает, что каждый экземпляр одной сущности должен быть ассоциирован с произвольным количеством экземпляров второй сущности, и наоборот [5] .

Любая характеристика сущности называется атрибутом, причем она должна быть значимой для рассматриваемой предметной области, а также предназначаться для идентификации, классификации, квалификации, количественной характеристики или выражения состояния сущности [5] . Определенная характеристика отдельного элемента множества называется экземпляром атрибута.

На данном этапе проектирования элементы моделей базы данных разрабатываются с учетом элементов модели классов, а именно: «классы отображаются в таблицы, атрибуты в столбцы, типы в типы данных СУБД, а ассоциации в связи между таблицами» [3]. Также возможно создание дополнительных таблиц.

В нотации IDEF1X отображают тип сущности, который определяется в зависимости от ее связи с другими сущностями: сущность может быть зависимой и независимой. При отображении идентифицирующей связи (сплошная линия на диаграмме) родительская сущность является независимой, а дочерняя сущность зависимой. А при отображении неидентифицирующей (пунктирная линия на диаграмме) связи дочерняя сущность остается независимой. Дочерний конец связи на диаграмме помечается жирной точкой.

...